Quote from: dandelO on December 02, 2010, 05:54:21 PM
Cool write-up there, cheers, TU.
When I use shaders that also enter the main network to drive the cloud functions, I've done it with only shaders right at the top of the chain, meaning that if I use a terrain heightfield for a cloud function, it hasn't even passed through any other nodes at all yet. The heightfield shader node allows you to colour any terrain from a black base to white at the highest points, there's a depth map right there. Colour adjusting to invert this gives you the reverse, obviously, which can be used to modulate clouds only between the peaks, that still mimic the terrain forms. I don't think it warrants the use of a separate image map of the terrain every time, unless you're passing the mask through many other nodes(probably most troublesome would be 'compute terrain' as it would triple calculation time of the functions entering the cloud shader) before it reaches the cloud.
I'd think using the black/white colour output of high up shaders in the network should be fine in most cases.
I see what you mean and I think you're mistaking by thinking that a heightfield-shader, it's displacement and derivement of colour is not so complex compared to an image map. It is.
Also, one would need to output an image map of the FINAL terrain.
In my example I kept things as simple as possible, so I made an image map of the terrain right after the compute terrain.
Logically, you can also make an image map of the terrain from the very last shader, preferably precedented by a compute terrain to make sure the output is correct.
The resulting mask perfectly describes the elevation of your final terrain. Perfectly, ok, that depends on the resolution you set in the heightfield generate node.
There's also no need to pass this mask through any other nodes, as it already is the map of the final terrain and you also make it for a single purpose.
