Surface Layer Smoothing Effect with Patchsize at and exceeding 20

[WAS]

Here is a better example with a large scale low octave mask, notice the PF at 0.25 dispalcement is now gaining meters of displacement above the computed displacement. On the sides of the mountains we have areas at 10+ meters, and on it's peak what looks like 30 or more meters. Haven't measured.

This issue wouldn't be noticed without this smoothing effect reverting to the computed terrain, as the added displacement conforms to the computed geometry and more or less looks the same + new displacement.

This exaggerated effect of the 0.25m disp PF is also either negative or postiive displacement, which explains surface layer alt restrictions, and added disp, and water levels out of whack at a distance and water poking through where it shouldn't be, by the logic of all the settings you have punched in. this has bothered me for years and couldn't figure out why it happened, and now it's starting to make sense.

In the foreground the displacement PF acts as it should, at a distance, where this mountain is about 7000-10000 meters away (according to this scene and initial SSS mask), the PF settings fall apart severely.

[Matt]

The issue is not the smooth layer but what is happening with shaders applied after the compute terrain.

The tiny stones, and tiny displaced PF should not be gaining displacement extents in excess of 30 meters. Where is this nonsense coming from defying the  laws of the shader settings?

The spikes are caused by the smoothing layer, not the small displacements. You can disable the other shaders between the smoothing layer and the Compute Terrain, and the spikes are still there. This is because there is a big difference between the height of the smoothed mountain and the height of the original mountain. Put the camera next to the mountain and you can see the issue clearly in the 3D Preview. When you enable smoothing, the mountain height is lowered by a large amount. This is related to the smoothing patch size. If you do a render of the smoothed mountain and compare it to the non-smoothed, you'll see a difference in height. The larger the patch size, the larger the difference.

[WAS]

Oh I see, now.

I have to say, a strange feature, that I can't think of any good use for, since it's so prone to so many oddities with even a simple terrain.

I just tried something now, and even trying to do soft snow up close, I found this created issues when I added soft undulation to the terror bird scenes hill (prior to compute terrain), and then had sunken snow melt.

Why doesn't it just revert to the Compute Terrain, and only the "soft version" when the Compute Terrain's smoothing effect is active? Because if I turn on that feature in Compute Terrain, the surfaces match fine. Seems like this "smoothing effect" could just smooth to the computed terrain, and if it is smoothed, to that smoothed terrain. Sure you can mask, but that's a lot of masking of X shaders you're using when it could just work correctly (in my opinion) from the get go and only use smooth if you're actually using it.

Ex. My scene already accounts for how smooth the surface needs to be for smooth snow in the initial terrain geometry, and doesn't need a smoothing effect of the compute terrain, I just need to cut through 14 shaders without having to mask all the surface shaders, plus masking of masks.

This is how I assumed it actually worked, and would be a good feature.

[Matt]

Why doesn't it just revert to the Compute Terrain, and only the "soft version" when the Compute Terrain's smoothing effect is active? Because if I turn on that feature in Compute Terrain, the surfaces match fine. Seems like this "smoothing effect" could just smooth to the computed terrain, and if it is smoothed, to that smoothed terrain.

Sure you can mask, but that's a lot of masking of X shaders you're using when it could just work correctly (in my opinion) from the get go and only use smooth if you're actually using it.

Ex. My scene already accounts for how smooth the surface needs to be for smooth snow in the initial terrain geometry, and doesn't need a smoothing effect of the compute terrain, I just need to cut through 14 shaders without having to mask all the surface shaders, plus masking of masks.

This is how I assumed it actually worked, and would be a good feature.

I can see how that would be useful sometimes. You can get the same result by setting the patch size to 0, so that's what I'd suggest in your case. If there are any other effects in your scene that need a larger patch size, you'll need a separate shader branch to handle those.

The way it works now, it is designed for the scenario where we want the smoother version of the data to be available for various effects, but we want the original rough terrain to be seen in some places. Some shaders, like the Alpine Fractal, need to generate the surface in a single shader. The way the algorithm works, we can't generate a smooth alpine first, then Compute Terrain, then add the smaller scale octaves afterwards. The Alpine Fractal needs to output final, rough surface with all octaves at once. Another example is loading a heightfield. If you want the full detail in some places but you want it to be smoothed in some places by the Surface Layer, the Compute Terrain has to output the detailed version.

If I were to make it optional on a per-Surface Layer basis, so you could choose between the way it works now or the way you want it to work, I would have to store more data in the render state which would add some overhead for all renders. That overhead would be pretty small, but these things accumulate with every such addition to the render state. I try to avoid things like that if there are other ways around it. It would also be Yet Another Checkbox With Confusing Consequences. Sometimes it's worth adding these options though.

[Matt]

I realised that my suggestion to use patch size 0 won't be good for the other displacements you have between the Compute Terrain and the smoothing layer.

You can either:

A) Use patch size 0 in the Compute Terrain, and use a separate Compute Normal with whatever patch size you need to calculate normals for your displacements.

or

B) Choose a small enough patch size that the smoothing effect doesn't displace the terrain by more than you're willing to accept. For example, if you're adding displacements of no more than a meter, and you're masking it by small details around 5 meters, I suggest you keep your patch size somewhere between 1 and 5.

[WAS]

Yeah. Pretty complex work arounds (that limit what you can even do) for that effect just working weirdly. It's odd it's using the smooth version of the compute terrain, that hardly anyone uses. It should be just the computed terrain, or smoothed terrain if that checkbox is explicitly selected, otherwise what real use is this? It's not going to smooth anything correctly in any conventional scene without these problems, even regardless of mask sizes. All because it's reverting to a smoothed compute terrain not even in use for displacement. This is just weird imo and possibly just not well thought out. I'd love for it work as it seems it should logically work, and just smooth of proceeding shaders to the computed terrain. And if it's smoothed, to that.

The only work around is doing masks to every shader as this scenes texturing is done via large patch sizes and intersections. Small patch sizes for foreground. So a patch size of 0 just isn't an option for trying to fix the issue in the distance. Otherwise I loose everything I worked for in texturing, and how snow follows the terrain.

Subsequently, if the intersection modes work as a child, I could just mask one or two surface layers carrying all the shading work, but alas intersections don't work when applied as a child to a terrain. Not sure if that can be helped though.

PS Thank you for at least chiming in and helping me realize what it is that's actually happening. Things make much more sense now. I think I may even be able to use the computed terrain with smoothing enabled granted I rough up some of the areas on the mountain. Not sure.