It appears that when you use the smooth height tool at the edge of the height map, points on the brush outside the mesh get treated as a value of 0 - so points on the edge of the height map rapidly approach a height of 0 while the other points in the brush area do more reasonable things.
I can’t imagine this ever being expected/useful behavior . Is there any way it’d be possible to make the edge points acts like a clamped texture for purposes of the smooth tool? Meaning, points sampled outside the height map return the value of the height map edge. I would think that’d result in much more reasonable smoothing results.
Or mask the brush so it only considers points actually on the height map when averaging?
It causes workflow problems in CityGen3D at the moment, where users want to independently work on adjacent terrains, but the smoothing routine creates an artificial drop on the edges, which is not desired if you later want to join terrains together.
As @DonkeyPotato suggests, it’s hard to imagine a scenario where this would be desired behaviour so a fix in BuiltinPaintMaterialPasses.SmoothHeights by masking the brush to the terrain would be preferable to having to retrospectively fix it in code before applying the terrain modification.
Edit (6/6/20): The heightmap smoothing function in CityGen3D now works without this problem as of v0.91
Ya, it’s annoying. It’s due to the kernel sampling and not discarding out of bounds texels in the height averages. We are looking into a fix to ship with our Terrain Tool package or one that will come as a patch to the package. The artifact gets really bad when you allow the user to bump up the kernel sample distance! Can’t say whether or not a fix will get into Editor source anytime soon.
This was driving me crazy (I mean really crazy) – but then I got Multiple Terrain Brush from the Asset Store https://assetstore.unity.com/packages/tools/terrain/multiple-terrain-brush-2-0-44037 and it handles terrain edges quite nicely. It’s annoying that Unity itself can’t handle this, but at least there is a tool that does. Using it in 2018.3, happy now. (It also handles painting at terrain edges better – I was often getting black pixels on the adjacent terrain, but this tool doesn’t have that problem)
Furthermore, completely ignoring this issue in Unity 2018 is unacceptable. Plenty of users are still on Unity 2018, and this issue being present makes using Unity terrain unbearably annoying. I’m using the GitHub terrain tools package which, if this information is correct, I have to assume is now officially abandoned in favor of the package manager version. This leaves us on Unity 2018 in the dust. Not happy.
