Problem with two compute terrain/normal for functional trees

[Goms]

hi,

a day of hard work is done, time for some fooling around.
i had the idea to use functions to get a "population" of fir(s?).
it looks great,- until the point where i want it to have a limited slope.

what i do:

- i use a voronoi diff to displace upwards, then i get the normal and displace a small noise along this normal.
- with a voronoi cell of the same seed and scale i managed to get a good coverage adjustment.
- also some variation is quite possible. (see picture below)

the problem is, as of the compute normal node i'm using, i can't manage to make the trees only appear within a slope under x°.
even if i use the terrain normal as slope key, the surface layer/ distribution shader is not using the compute terrain node, but the compute normal node....
therefor the colors are not shown, as soon as i use some slope limitations.

any ideas are welcome, as this is my best approach to functional trees until now!

attached the tgd, if anybody wants to play with it

[FrankB]

as a first and instantaneous reaction my mind is telling me that the compute normal just doesn't know about the terrain shape at this point. Maybe you could employ a different method, such as creating a mask from a distribution shader in the main tree, and use that as a blend shader for the surface layer with your trees. Uhm sounds confusing, but it's what I mean.

Regards,
Frank

[Goms]

yep, thats exactly what came into my mind first too.
the problem is how the shader gets his slope key, i guess. because its working great until the point where this network gets plugged to the blend input.
from there on its using the compute normal. :/

thx anyway, every input will help!

[Tangled-Universe]

yep, thats exactly what came into my mind first too.
the problem is how the shader gets his slope key, i guess. because its working great until the point where this network gets plugged to the blend input.
from there on its using the compute normal. :/

thx anyway, every input will help!

The distributionshader used to get his slope key different from a surfacelayer, but that has been fixed already. I don't know how that is for the defaultshader at the moment? It might be that you need to bypass the use of a default-shader since that might not get the slope key correctly as well.

[Tangled-Universe]

Is it me or is the reason for this very simple?

If you set a constraint for the trees you automatically constrain for the colour as well.
When I set a max slope-constraint at 90 degrees and 0 fuzzy zone I have green trees.
If I reduce that gradually the trees also gradually lose colour.

Don't ask me how, but you should need to split the displacement-part from the colour part and merge that together later.

[Goms]

i don't think its a problem of any of these layers.

i deleted the default shader and tried both, surface and distribution shader. none of them worked.

Also, if i use a surface layer with only color and slope limitations after the tree network, its also using the compute normal. :/

i tried to split the displacement and the color, but won't work either...
even tried to apply the color before the displacement. still the same.
also my light-green layer is gone on the trees; even if they re not colored at all.

so my conclusion is: tg2 uses the last compute node within the node-network; even for shaders that are applied before.
a compute terrain shader with a greater patch size just before the input into the planet confirmed this. then its using this compute node.

--> no matter what i do, every limitation in slope will *uck up my trees.


a great new function therefore would be something that takes an input, and then only outputs the color, just using what was done before.
or, what would be best, you can choose which compute node is used in the shader.


... and they looked so decent from above...

[Tangled-Universe]

Hmmm...I think I don't get it...I only lose the colour, not the displacements itself?

I'm pretty sure that TG2 is not only using the last compute node in the network, otherwise you wouldn't have to compute the terrain before applying texturing or wouldn't have to compute the normals when adding multiple layers of displacements.
Since you're only having one compute node in the main chain before the planet you can't be sure about that. (the second you have is as a child in relation to the main network)

I can't tell you exactly what you're missing here, I'm sorry, but there's something we're overlooking here.

[Goms]

i think for displacements this works as, but not for colors. i did some testing:

a simple ramp with a surface layer, set to slope 40 with 10 fuzzy zone and terrain normal as slope key and compute terrain 01 deactivated:





now with compute terrain 01 activated. this is now used as slope key, even is the surface layer comes earlier. thats how expected.



this is an added surface layer after the compute terrain 01, slope 30 10. uses compute terrain 01 as key, just as compute terrain should.



here i added a displacement to the second layer, but did not change anything else. still, everything fine.



and now i activate compute terrain 02 after the displacement but before the input to the layer. both layer use this as key now.



and now i activate the third compute terrain, after everything else, with a greater patch size. both use this one now.



and using compute normal instead of compute terrain does not help.
file attached.

[Tangled-Universe]

Hmmm...I think you made a mistake in your conclusion when activating "compute terrain 02".
Both layers do not use this compute node as key.

You can check this by disabling the pink layer, keep compute terrain 01 activated and disable compute terrain 02.
Compare that with the result where compute terrain 02 is activated.
They are the same, so compute terrain 01 is used as key.

Now let's disable compute terrain 01 and enable compute terrain 02. (compute terrain 03 is still disabled!).
Now the terrain is displaced with voronoi.
This tells me that the compute terrain 02 is not aware of the terrain above the blue surface layer.
As Frank mentioned.

[Hetzen]

Not sure what to suggest Goms.

I agree. I think it would certainly be useful to have an option to select which (compute terrian/normal node) you want a (get function) to calculate from. Maybe a use for the input on the Get functions to 'asign shader' to?

[Goms]

Hmmm...I think you made a mistake in your conclusion when activating "compute terrain 02".
Both layers do not use this compute node as key.

You can check this by disabling the pink layer, keep compute terrain 01 activated and disable compute terrain 02.
Compare that with the result where compute terrain 02 is activated.
They are the same, so compute terrain 01 is used as key.

hm, heres a picture of what i get. i deactivated the pink layer and compute terrain 02 (and 03 of course).



and noe i activated compute terrain 02 (03 still disabled. 01 is still enabled.



and now with 01 disabled.



the displacement seems to use the right one, as it looks the same in the first and the second image, but not the color...

Now let's disable compute terrain 01 and enable compute terrain 02. (compute terrain 03 is still disabled!).
Now the terrain is displaced with voronoi.
This tells me that the compute terrain 02 is not aware of the terrain above the blue surface layer.
As Frank mentioned.

yes, but as said, just the displacement part. or do i still miss something?
my point is, that the blue color in the second image is using the compute 02, not 01 as the displacement does.


best regards,
Goms

[Tangled-Universe]

I don't know Goms. To me it looks the displacement and the color both use compute 01.
You have restricted the displacements to 30 degrees and that works. The color also seems to be restricted to 30 degrees.
The compute 02 does nothing I think.
I will have a look at this again when I'm back home.

Hopefully Matt can chime in here.
I think this discussion is quite essential.

[Goms]

yep, basically your right. but thats my problem,- kind of.

the blue color is limited to 30° - on everything, not just at the point where compute 01 was used.
what i would expect with compute 02 activated in addition to 01, is a result as in the first picture.
(as its behind a layers child input. i was just not expecting the surface layer to use the childs compute as key for the slope.)
like the displacement is computed and then gets displaced again (like i did to my trees), and then limited to the compute terrain 01.
i was always expecting this when i used a compute normal, but as said this also happens with this node.


best regards,
confused goms

[TheBlackHole]

Ignore this post.

[Tangled-Universe]

Set your displacements as a child layer to a surface layer with slope restrictions.

Ehhrr...how much did you actually read from all of this?