Intersect underlying mystery

Started by sboerner, November 28, 2020, 05:38:52 PM

Previous topic - Next topic

sboerner

I'm using intersect underlying to add a thin layer of snow to a scene consisting of a nearly-flat foreground with hills in the background. A canal channel crosses the scene, created with a warped simple shape displacement mask. Based on examples found on the forum the displacements are routed through two compute terrain nodes, one with a small patch size (20) and one with a larger (200). The larger patch size goes to the snow surface layer with intersect underlying enabled.

OK so far.

The problem is that the mask used to create the canal is getting multiplied across the landscape. The "shadow" masks don't create displacements, but they do mask out the snow layer. Adjusting the intersect underlying settings can help somewhat but they don't remove the extra masks. Somehow they're related to the second compute terrain, because changing the patch size changes the distance between the duplicates and the original displacement.

Instead of averaging out the canal displacement, the second compute terrain just seems to be repeating it. But the duplicates only affect the intersect underlying shader.

I stripped the scene down to the bare essentials and cannot find a way to fix it. Maybe there's a problem with the basic setup?

Dune

#1
I'll have a look, but the first thing coming to mind is to make the canal after the last compute. I've had trouble making a scene like this, with large fields of snow in distance and small in closer low areas. It's difficult anyway.

EDIT: Something like this may work. But it depends if you need intersect to work on smaller scales in the front area.

sboerner

Thank you for setting that up, Ulco. I'll look at it later this evening but it looks like you avoided the multiple masks. Maybe using two compute terrains was causing it?

I think I understand the basic concept – that intersect underlying "intersects" the current version of the displaced surface with an earlier, smoother one. But making the leap from concept to concrete results has been a dependable exercise in frustration. So many questions. Where does the "underlying" surface come from? How do you set that up to get the result you want? What do the sliders do? Baffled here. I hate to admit this, but I don't understand it well enough to set up a decent test scene to find out how all of the controls work.

A detailed walkthrough from someone who really understands how this works – explaining both theory and implementation – would be so helpful.

WAS

I wonder if it would look natural if you blended the intersection scales with a distance shader. Get the nice snow accumulation in the BG and smaller scale in the FG. I still don't fully understand what exactly this does on a realistic level. I know sometimes I can get some really nice natural looks, and sometimes I can't get it to play nice at all. And others I've noticed no effect when a texture coordinates are in play. Seems to dump the compute terrain data it needs.

Dune

XYZ shader messes that up indeed as it 'fixes' the loactions, sort of. Handy if you need softening/smoothing something after some shaders that need to stay as they are, but not with intersect.
I used to have trouble with a combination of altitude or distance masks in combination with intersect, as it produced a hard line. Also made using snow hard as these 'shadows' popped up in part of the snow areas. It probably has to do with the calculation of a smoother version of the initial terrain via the patch size (I guess the same way the smoothing shader works), as early on I had these triplet shadows as well. I haven't used the intersect very much lately (flat country we live in), so I'm not exactly sure if these are fixed in some way.
The sliders 2 and 3 shift the altitude of the smoother version of the initial terrain, I guess. The first the size of intersection in meters. With very small sizes (cm) and a first negative and second positive shift, you can get interesting results, but don't ask me to explain :P

KlausK

Steve, in your file "intersectUnderlyingProblem.tgd" you only need to set "Fuzzy Zone Softness" in the snowSurface node to "0".
That gets rid of the shadow masks. Of course I do not know if that always helps and/or if has other unwanted effects on more complex scene setups.

CHeers, Klaus
/ ASUS WS Mainboard / Dual XEON E5-2640v3 / 64GB RAM / NVIDIA GeForce GTX 1070 TI / Win7 Ultimate . . . still (||-:-||)

sboerner

QuoteSteve, in your file "intersectUnderlyingProblem.tgd" you only need to set "Fuzzy Zone Softness" in the snowSurface node to "0".

That gets rid of the shadow masks. Of course I do not know if that always helps and/or if has other unwanted effects on more complex scene setups.
Thanks, Klaus. I did try that, and you are right that it has other effects. This is the risk of oversimplifying a scene for testing purposes. In the actual working scene, setting fuzzy zone to zero doesn't eliminate the shadow masks. And it obliterates the fine detail in the foreground.


Maybe intersect underlying is meant for alpine scenes, where it's easy to set up, and not for more nuanced landscapes. But I'm not convinced of that. Doubling down on this today and will post an update.

sboerner

OK so the light bulb finally came on and it's like 1000 watts or so.

Thanks again to Ulco for the sample file (and his previous posts on this subject). This thread in particular was very helpful. A post in it by Martin is worth quoting at length:


QuoteThe shader uses the terrain's state from the last compute terrain. This compute terrain does NOT need to have smoothing enabled.
For best results the surface layer shader asks to enable smoothing, so do so.
The surface layer shader then generates a smoothed version of your last compute terrain before that surface layer shader.

The smoothed result's smoothness depends on the gradient patch size of that compute terrain.
Indeed, the smaller the gradient patch the more details the smoothed version of the terrain will have.
Yet, it will always be smoother than the unsmoothed, so with the right settings you will always see some kind of effect of IU with DI.

Now the intersection zone is a parameter which determines a kind of step size to read the smoothed version of the terrain as provided by the last compute terrain.
It will compare both states and determines where the two "intersect", which is mostly in depressions.
You can imagine this by having a sinus shaped terrain from -0.5 to 0.5m, which upon smoothing is flat @ 0m (for example).
With DI you can now "fill" the negative/depressed parts of the sinus shaped parts.
With correct settings you can even "fill" them completely.

Small values for intersection zone allow for detailled "filling" of smaller depressions.
High values for intersection zone uses large chunks of smoothed terrain and allows for filling large depressions, but as a consequence can also add a thick layer over non-depressed surfaces.


Here is what I take from this:

The patch size of the preceding compute terrain drives the scale of the intersection. For large-scale alpine scenes, use a very large patch size. For nuanced, small-scale scenes, use a very small patch size.

Smoothing in the i/u layer must be enabled and set to 1, regardless of the type of intersection (favor rises, depressions, or displacement intersection).

Intersection zone is the vertical depth of the, well, intersection zone. In meters.

Intersection shift vertically adjusts the offset of this zone. In meters.

Min intersection shift can be used to choke the distribution of the intersection. The closer it is to intersection shift, the more contrast in the distribution.


For my scene, the compute terrain must follow the canal displacement because the canal is going to be drained. (There will be a bit of water in the bottom in the final version.) This is a relatively small-scale detail (~12m wide), so a large patch size (as in my original scene), won't work. The answer is to use a small patch size. It's now set to 3.

The snow surface layer has i/u set to favor depressions with an intersection zone of 1 and an intersection shift of -0.5 to expose the very slight vertical displacements. A breakup shader adds more texture.

The small patch size means the hills in the background are now completely covered with snow, but that looks natural here and they will be covered with trees anyway.

Finally, a question for @MattThe thread referred to above includes several references to detailed, in-progress documentation for i/u. If it isn't too much trouble, can this to be made available on the wiki or forum? I wonder if it might be worthwhile, even if it's not complete.

WAS

The canal looks great now but the background distribution looks very muddled at the foreground scales, not very realistic accumulation or face melt. 

I'm sure you can use a distance shader to not only merge two different compute terrains with not much render impact but also interestion settings. Ive done it a few times and I think Ulco's scenario may be something else or transition too close to the camera.

sboerner

QuoteI'm sure you can use a distance shader to not only merge two different compute terrains with not much render impact
Thanks, I had thought of that but am deferring that step until all of the ground cover and trees are in place. (Tree coverage in distance will be near 100 percent.) I'm guessing it will be unnecessary but we'll see.

Dune

QuoteFor my scene, the compute terrain must follow the canal displacement because the canal is going to be drained
This I don't understand. Is it going to be an animation? But even so, I think you can use my setup, and still drain the canal. Just lower the elevation in the water line, locally perhaps by some mask like a distance shader.

You can also have large fields of remaining snow in foreground by a PF patchyness, again, masked by distance shader (and the canal, e.g.), and have the ground flattened and snowed in some areas, even bulging up a bit, or working the other way around, only have detail in some parts and keep the rest snowy and soft.

KlausK

"This is the risk of oversimplifying a scene for testing purposes."

Yeah, that would have been too easy and nothing like you. Even though I hesitated to post this...you never know, right ::)

CHeers, Klaus
/ ASUS WS Mainboard / Dual XEON E5-2640v3 / 64GB RAM / NVIDIA GeForce GTX 1070 TI / Win7 Ultimate . . . still (||-:-||)

sboerner

QuoteYeah, that would have been too easy and nothing like you. Even though I hesitated to post this...you never know, right ::)


No reason to hesitate! I appreciate the feedback, believe me. You never know. :D

sboerner

QuoteThis I don't understand. Is it going to be an animation? But even so, I think you can use my setup, and still drain the canal. Just lower the elevation in the water line, locally perhaps by some mask like a distance shader.
No animation. You're setup is good and it taught me a thing or two. My thought was that by placing the canal before the compute terrain, it would then become part of the smoothed, underlying displacement calculation and would lead to natural-looking drifts and filled-in snowbanks on the sloped canal banks. I'm pleased with the result to be honest.



QuoteYou can also have large fields of remaining snow in foreground by a PF patchyness, again, masked by distance shader (and the canal, e.g.), and have the ground flattened and snowed in some areas, even bulging up a bit, or working the other way around, only have detail in some parts and keep the rest snowy and soft.
Yes, and thanks for the tips. This can still be done. The picture is very much a WIP and there is foreground detail to be added as well as ground cover and trees.


For the canal itself, attached image is getting close to the final result. (Lighting still needs to be finalized and improved, too.)