Surface Slope Limitations Question

[WAS]

So, I'm wondering. Is it possible to have a Surface Layer that has a slope limitation, but that slope limitation not effect it's child, but respond to the main input? Or is there a way around this some other way? When adding fine detail to the children, the main surface layer will respond by cutting off at slopes it seams and creating hard Base colours coloured areas. So you end up with specs of Base Colour through your textures when fine displacement exceeds the max slope. But you do want it to respond to the main terrains slopes.

[Oshyan]

Children are limited to the distribution of their parent fundamentally speaking.

- Oshyan

[WAS]

Children are limited to the distribution of their parent fundamentally speaking.

- Oshyan

Hmm. I wonder if there is a way around cause it is a little obtrusive to work flow. You'd think the childs could have whatever displacement, and the limitations would only apply to the main input terrain, especially with the need of a Compute Terrain for certain functionality. And than the childs displacement would be cut at the MAIN displacements slopes, not it's own.

It sorta breaks the "Surface Layer" logic inherently by definition.

Mind you there is 20 meters of fuzzy zone for these slopes, so the breakup [and no fractal breakup] is more anomalous because of this master slope limitation and it's children. These displacements are on the 0.009m scale. The breakup doesn't even necessarily conform to hard angles in the displacement seem random, and on smooth angles too.

[Oshyan]

Maybe I just don't understand what you're asking about. But children are limited to the distribution of their parent entirely by design and it seems quite logical to me. I see some tiny differences in your test images (they look like little grey rocks or something), but I'm not able to link your explanation to the visual outcome there, it's not making sense to me.

- Oshyan

[WAS]

The surface layer is on a flat planet surface, with a child network.

Like, the slopes shouldn't be causing this on this low of displacement. The limitation is set for 60 with a fuzzy zone of 20m, so even if it did start to clamp at slopes, there should be literally meters of near solid colour.

Trying to figure out how I can have "grass" like tufts and mounds, and overlay that onto a terrain and limit by the terrains slopes, not by it's own slopes.

[Matt]

There are some options in the "Slope Key" on the Slope Constraints tab. The way the renderer works, colours/shade are calculated after the whole displacement network has been calculated, and the surface normal at this point is called the "Final normal". But we also have access to an earlier version of the normal which is computed by the Compute Terrain or Compute Normal node, and is called "Normal in texture/terrain". You can choose which of these you want to key off for the slope constraint.

[WAS]

There are some options in the "Slope Key" on the Slope Constraints tab. The way the renderer works, colours/shade are calculated after the whole displacement network has been calculated, and the surface normal at this point is called the "Final normal". But we also have access to an earlier version of the normal which is computed by the Compute Terrain or Compute Normal node, and is called "Normal in texture/terrain". You can choose which of these you want to key off for the slope constraint.

What's sad is how obvious that seems and didn't even think about it, yet is routine when using the altitude system. Lol Going to give that a test.

[N-drju]

You'd think the childs could have whatever displacement, and the limitations would only apply to the main input terrain, especially with the need of a Compute Terrain for certain functionality. And than the childs displacement would be cut at the MAIN displacements slopes, not it's own.

It sorta breaks the "Surface Layer" logic inherently by definition.

I don't really agree, because if surface layer would affect an input then an entire network would need to take whatever slope and altitude limitations are set there.

Besides, a child function is used as an alternative to an, otherwise, useless one-color surface layer. If there was just a monochromatic, global-working SL with no childs, how useful would that be?

[WAS]

You'd think the childs could have whatever displacement, and the limitations would only apply to the main input terrain, especially with the need of a Compute Terrain for certain functionality. And than the childs displacement would be cut at the MAIN displacements slopes, not it's own.

It sorta breaks the "Surface Layer" logic inherently by definition.

I don't really agree, because if surface layer would affect an input then an entire network would need to take whatever slope and altitude limitations are set there.

But that's exactly what's happening, N-drju...? The child network takes whatever slope and altitude limitations, no matter how big and elaborate. Applying slope limitations from the main surface to all child surface layers. That's just wrong. If I wanted too, I'd apply it to each individual surface layer within.

Again, this defeats the logic of surface layer in any program out there. They're absolute in masking unless you mask out areas, apply blending modes or displacement mixers, etc.

It also defeats the purpose of compute terrain and applying a surface over it....

This is why we have, as Matt mentioned, other slope keys that I had just forgot about.

Think of it like this... snow is used in a surface layer a lot with a offset, and it's own small displacement tufts, but snow doesn't tend to cling to such extreme slopes as default slope of 60 degrees, so you lower it to something more appropriate like 45 degrees. Now your snow is cutting off on it's own snow displacement. Lol

The default slope key is sorta just wrong for most uses. Sand, dirt, grass, snow, etc. These type-surfaces buildup on the main surfaces.

Besides, a child function is used as an alternative to an, otherwise, useless one-color surface layer. If there was just a monochromatic, global-working SL with no childs, how useful would that be?

That's how surface layers work by default... xD lol They're meant to apply colour texturing, and do not work well with child displacement. Lol

[Matt]

You two are not understanding each other, that's all.

I, too, didn't understand what WAS meant by "affect an input", but after further reading I realised that what he really meant was "be affected by an input".

The lesson to be learned here is that if someone says something that doesn't make sense, consider the possibility that they meant something that does make sense, and figure out what that is.

[Matt]

But that's exactly what's happening, N-drju...? The child network takes whatever slope and altitude limitations, no matter how big and elaborate. Applying slope limitations from the main surface to all child surface layers. That's just wrong. If I wanted too, I'd apply it to each individual surface layer within.

I must be misunderstanding you. Because, the idea, the purpose of the child layer functionality is that child layers are limited to the same constraints as the parent layer. If they're not, then why are you making them child layers instead of separate layers? Child layers have no other purpose than to be constrained by the same mask(s) as their parent.

Now, sometimes this idea doesn't work in practice (as you discovered), and that's because of the different kinds of normal that you can key off, and the order in which displacement and shade are calculated by the renderer. That's why we have options to choose between different kinds of normal, some of which will be better than others for different situations. But the philosophy of using child layers remains the same.

It's not intended to be affected by displacement caused by the child - that's an unintented side-effect, which can be solved by using a different setting for slope key. But "final normal" is the default because for many uses where there is no child layer "final normal" gives a more detailed and interesting render.

[WAS]

But that's exactly what's happening, N-drju...? The child network takes whatever slope and altitude limitations, no matter how big and elaborate. Applying slope limitations from the main surface to all child surface layers. That's just wrong. If I wanted too, I'd apply it to each individual surface layer within.

I must be misunderstanding you. Because, the idea, the purpose of the child layer functionality is that child layers are limited to the same constraints as the parent layer. If they're not, then why are you making them child layers instead of separate layers? Child layers have no other purpose than to be constrained by the same mask(s) as their parent.

Now, sometimes this idea doesn't work in practice (as you discovered), and that's because of the different kinds of normal that you can key off, and the order in which displacement and shade are calculated by the renderer. That's why we have options to choose between different kinds of normal, some of which will be better than others for different situations. But the philosophy of using child layers remains the same.

It's not intended to be affected by displacement caused by the child - that's an unintented side-effect, which can be solved by using a different setting for slope key. But "final normal" is the default because for many uses where there is no child layer "final normal" gives a more detailed and interesting render.

That's not how layers work in most programs. Children are their own subset with their own definitions, applied over the parent structure. This means the follow the constraints applied to the main element, not themselves.

Terrain Normal provides this functionality seen most everywhere else. As you explained, the Final Normal takes into account everything, which is not how most layer systems work. It is an absolute layer applied to something else. It could have a whole mountain on it that wouldn't be effected by the parent except for where it's contsaints follow it's underlying layers (not children)

It makes no sense to have a mountain as a child, and than the parents slopes, height, etc, apply to the children's fine displacement, but instead the underlying network of the parent, not the children of that layer. I honestly don't see many practical uses for this and explains peoples hard grass on displacement broken up everywhere.

[WAS]

Take this crude example. I'd find "terrain normal" would be the normal default method for a logical, normal, approach to layering seen most everywhere. Not arguing anything is wrong, just the default "Final Normal" produces very erroneous results for landscaping imo, where layers, a literally, often built up.

I do notice with Terrain Normal though, that slopes are harder to control, not sure if that's cause of lateral displacement and using a tex to coordinates for data for layers.

[Matt]

That's not how layers work in most programs. Children are their own subset with their own definitions, applied over the parent structure. This means the follow the constraints applied to the main element, not themselves.

As it does in Terragen. The discrepancy you see is between displacement and colour/shade, not between parent and child. If you work only with colour, it works (because there is no displacement to interfere with expected results). If you work only with displacement it works (because displacement can only use "normal in texture/terrain", it has no access to "final normal", and the latter is where problems arise).

Terrain Normal provides this functionality seen most everywhere else. As you explained, the Final Normal takes into account everything, which is not how most layer systems work. It is an absolute layer applied to something else. It could have a whole mountain on it that wouldn't be effected by the parent except for where it's contsaints follow it's underlying layers (not children)

It makes no sense to have a mountain as a child, and than the parents slopes, height, etc, apply to the children's fine displacement, but instead the underlying network of the parent, not the children of that layer. I honestly don't see many practical uses for this and explains peoples hard grass on displacement broken up everywhere.

Perhaps. "Final normal" adds a level of detail that isn't available in "Normal in texture/terrain" which is often desirable IMO (you can try applying snow and grass with "Normal in texture/terrain" but it's not ideal IMO). But there are plenty of situations where it's problematic too, so we provide both options.

[WAS]

That's not how layers work in most programs. Children are their own subset with their own definitions, applied over the parent structure. This means the follow the constraints applied to the main element, not themselves.

As it does in Terragen. The discrepancy you see is between displacement and colour/shade, not between parent and child. If you work only with colour, it works (because there is no displacement to interfere with expected results). If you work only with displacement it works (because displacement can only use "normal in texture/terrain", it has no access to "final normal", and the latter is where problems arise).

I don't really understand that. If you use colour only, it works, if you use displacement only it works, wouldn't they both than work?

And the problem with displacement seems to be a combination of issues with the two, as just like fake stones, it will break all the way down the very first/last "Base colour" shader or whatever you may have in place of it. Ignoring even other surface layers tied into it's main input. Seems like just brokenness, like something causes it ignore other surface layers plugged into main like fake stones and show base colour.

Like I mentioned earlier, there could be literally meters of fuzzy zone (like 20), but a simple 0.0045m (up to whatever, I think max of the terrain was a offset of 0.01 or 0.1) displacement will have a hard break to the base colour.