Biblical Desert

[Matt]

The shader that's plugged into "mix controller" is only asked to produce colour. The displacements on that branch are never called, so the Heightfield Shader will never produce any altitude that the Distribution Shader could use.

In your setup, the Distribution Shader sees the altitudes from whatever displacement was done by the Input of the Merge Shader.

Matt

[Matt]

I think I might have been wrong about what the mix controller sees. I think the way the Merge Shader works, the mix controller never sees any displacement from any of the inputs.

If you're just adding displacements to an existing terrain, why not use the "blend by shader" option? The distribution shader will work in that case.

Matt

[monks]

Thanks Matt, I 'm not understanding some basic things- like there was a division between colour and displacement in TG. But now you point it out it does seem to be theme in the nodes and would make sense, xy and z. My biggest problem is understanding the node input descriptions.
I'll keep playing with it but I'll probably need to take a detour into a tut or two

monks

[Oshyan]

I haven't looked closely at this, but just from the sound of  how you're talking about using the Distribution Shader, it sounds like you're going about in a slightly incorrect way. You would want to plug the Distribution Shader into Merge Shader's "Mix controller" input to control the mixing of your Heightfield with the base terrain. Alternatively you could plug the Distribution shader into the Blend Shader input of your Heightfield.

However the biggest problem with what you're trying to do is probably that it all comes before the Compute Terrain, so there is no existing computation of slope/altitude for the Distribution Shader to work off of. See this fine explanation from Martin in another recent thread:
http://www.planetside.co.uk/forums/index.php?topic=14673.msg143626#msg143626

- Oshyan

[monks]

I understand the Compute terrain node now. Basically that's the computation of the surface, so better to have all major terrain alterations before that- or so I read. Apparently you can also use get x/y position from the heightfield to place textures. Looking briefly at that thread yes!...texcoords from xyz and the I was beginning to think that more than computer normal could be useful- I was in the habit of thinking that you only had one compute normal in the network because that's how the default project is laid out. But of course, there's no hard and fast rule like that.

I did try using the distribution shader into the mix controller that way and I seemed to be getting somewhere at that point. Then we had a power outage in the area...and I lost it. The thread will be more help. If I can get to the point where I can view the nodes (or combination of them) as equivalents to World Machine nodes, then I'll be happy. I think that thread and basic workflow explanation by Martin should be put into some kind of tutorial. 

monks

[monks]

I think I can do this another way since I'm not combining two heightfields, I'm combining (with altitude constraints), a fractal terrain with a base heightfield. So basically if you put a surface layer in the network it doesn't necessarily hide the terrain that was before it in the terrain, because all you do is alter the height/slope constraints. Obvious...but what's less obvious is I have to plug the fractal terrain into the child node of the surface layer. But the child node is above the parent node in the network view, when the whole flow of the network is down to the planet node. That's the confusing aspect. The Shaders tab view makes visual sense.

monks