The smoothing effect seams to be creating erroneous peaks around the boundaries of smoothing effect surface layers when the patch size is too large (eventually for large intersection texturing).
It's even noticeable with just the default patch size of 20, where the offset of this smooth area is only 0.25 but at great distance on the mountain we can see roughness into a meter or more.
Probably should note, this is 4.5.56 SR didn't try PT as I didn't think it'd matter.
If anyone knows a way to prevent this I'd be interested to know, as I had a nice snow scene that works well for the snow parts up close but is disastrous at a distance for the mountain. I tried displacement tolerance but that didn't work. I also tried mixing the terrains with masks but was having boundary texture issues in my first attempt that looked very bad.
I'll have a look...
As for your comment on my Terror Bird thread about the renderer having issues calculating the smooth areas. You'd think this would just be a mask based on what the surface layer is covering, and would act like such. Similar to just masking a surface layer. But culling displacement along the fuzzy zone to where the surface layers density is 1.
But with this causing an issue with event he default patch size, in a default scene, I'd say it's a bug that should see improvement. I've never really used the feature because I was told to do it with Fake Stones, but noticed it broke stones worse, which may have actually been this bug. But for sprawling terrains, and texturing, this is very much buggy and not usable.
A patch will have an average sort of altitude, so I can imagine if you then smooth by a smaller PF, not all areas are smoothed the same way, hence the strange displacements. But does it occur only in the distance like in your sample? Then a distance shader might help to mask that out.
The issue is the smoothing effect is incorporated into the distant texturing work, smoothing out rough areas to apply smooth rolling snow on the mountain.
It is one of its uses, and shouldn't be limited to the immediate foreground imo. It even causes issues as mentioned with just the default patch size of 20.
These patch sizes are pretty crucial for intersection texturing. As too small, and it's adhering to small displacement vs larger (with smaller integers).
Still, if you mask smoothing by a fractal with minimum size of 10cm you could get in trouble. I would set this up in layers I guess, with the smaller masks only in front areas. There's a sweet spot around 50-100 patch, but that depends on terrain, I think. Higher and it gets really spikey. And, as said, when you check smooth surface, it's working nicely.
For really smooth snow, you should take out the fractal warp too, as that doesn't react fully on smoothing. Better mask that in later.
Don't think it's related, Ulco. As you can go ahead and apply a distance shader, or mix in two maps with a smoothing effect into 20+ and still a issue. Now you can just plainly see that the displacement 0.25 of the PF being smoothed is now reaching 20-30+ meters, then being smoothed. Seems to be something entirely different in computation with the compute terrain.
Seems to be that displacement shaders added after the Compute Terrain do not follow their settings constraints at a distance, and start doing weird stuff, like gaining ridiculous excessive offsetted displacement.
So you must find a workaround ;) Not everything is perfect, I'm afraid.
Or, there is a clear bug with distant displacement and the smoothing feature.
The shader doesn't state we can only use it in the foreground, because the sampler goes nuts. Lol
Quit just shrugging off stuff like this, Ulco. You don't help TG look good... The contrary...
It seems obvious to me that either displacement at a distance isn't following it's settings right, at all, or the smoothing effect is causing the issue with excessive displacement gain. With the first scenario this can literally be an obstacle for normal terrain work and create undesirable effects at a distance. With the second, it breaks the use of a shader to exclusively use it in the foreground... Both of these scenarios aren't very good... Finding "another way" is implied. Doesn't mean there isn't an issue...
Well, you may be right about the bug, but I just don't have too much time to worry about this now, hence my 'shrugging off'. I still think if you mask a 'to be smoothed' area by small detail, you're bound to get weird artifacts. Not in the front, because the initial displacement is tiny or absent, but as soon as terrain goes up or down, these mismatches with computed terrain may play havoc (because of the mask).
Too smooth out certain smaller displacements like you have in front, I would always use an XYZ shader after the big displacements to 'fix' the big ground. The compute terrain has a certain patch size to consider (and slows down), hence my choice. Any added smaller displacement after that can be smoothed by whatever, and not affect the mountains over yonder. Maybe that's a 'workaround'?
But. Again. Patch size doesn't matter. Could be default, lower, or ridiculously high. The issue is always there. Also doesn't matter if the mask is low octave or high, small or large scale.... Again issue with disp is still there.
I am thinking its the sampler and dynamic polygon settings that cull detail at distance, and are not following the laws of the shaders applied at a distance. Such as growing 30+ meters above computed displacement from a PF with 0.25m displacement...
And you may not have the time to worry, but I do believe this is support for staff/development. But at the same time definitely doesn't give me confidence for the alpha program, and kinda reaffirms my opinions on why so many bugs get through cause alpha tests aren't really testing and straining TG to discover bugs. Beta/alpha testers should be trying to break the program (sarcasm). :P least from my years at Xbox beta testing and software testing.
Gotta say though, no staff or dev (Matt) responding to support topics or selectively approaching them is a bit annoying.
Hi Jordan,
"Smoothing effect" in the Surface Layer reverts the surface back to a smoother version of the most recent Compute Terrain or Tex Coords from XYZ. The larger the patch size, the larger the difference is likely to be.
In your scene the issue is caused by the mask you are applying to the surface layer. The mask has some very high frequency (small scale) and high contrast components, and these are causing the surface to rapidly switch between the smoothed and non-smoothed surfaces. I don't think there's a bug here, just a particular combination of shaders producing an unwanted result.
One way you might be able to resolve this is to reduce the roughness of the masking fractal.
EDIT: The mask's "feature scale" is currently 5, and this will need to be much higher if you don't want spikes. It probably needs to be at least as large as the patch size.
EDIT 2: You can increase the sharpness of the mask's effect on colour only by reducing "Fuzzy zone softness" on the Effects tab. When it's set to 1, the colour and displacement use the same mark sharpness. The idea is that you use low contrast (or low frequency) masks so that they don't create spikey displacements, and then lower the "Fuzzy zone softness" (e.g. 0.1 or 0.01) to bring out some sharpness on the for colour/shading only.
Quote from: Matt on May 27, 2021, 04:41:33 PMHi Jordan,
"Smoothing effect" in the Surface Layer reverts the surface back to a smoother version of the most recent Compute Terrain or Tex Coords from XYZ. The larger the patch size, the larger the difference is likely to be.
In your scene the issue is caused by the mask you are applying to the surface layer. The mask has some very high frequency (small scale) and high contrast components, and these are causing the surface to rapidly switch between the smoothed and non-smoothed surfaces. I don't think there's a bug here, just a particular combination of shaders producing an unwanted result.
One way you might be able to resolve this is to reduce the roughness of the masking fractal.
EDIT: The mask's "feature scale" is currently 5, and this will need to be much higher if you don't want spikes. It probably needs to be at least as large as the patch size.
I have tried large scales, low actives, high octaves. I stated this, and explained the actual issue being exaggerated by the mask
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?
This is where the smoothing layer is producing bad effects, because reverting to the Compute Terrain is revealing a bug in how displacement is being handled at a distance from the PF (displacement PF not mask PF of smoothing layer).
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.
Quote from: WAS on May 27, 2021, 04:51:04 PMThe 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.
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.
Quote from: WAS on May 27, 2021, 05:35:58 PMWhy 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.
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.
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.