xfrog-plants don't want to sit on terrain

Started by _duke_, March 08, 2010, 07:40:18 AM

Previous topic - Next topic

_duke_

hi there, i searched the forum, but i didn't find any solution.
I created a population of plants. But all the trees appear on a flat layer clipping through the landscape or beeing overdraw from it. I know, that it has something to do with the "sit on terrain" shader. I have choosed of course the "compute terrain", but that has no effect at all. The thing is, no matter which shader i choose here, nothing happens except the all populated trees move a bit down.
I have my Node Network attached. Maybe it's necessary. Thank you.

regards,
Daniel

Henry Blewer

I ran into a similar problem not too long ago. At the end of the shaders node chain, add a compute terrain to plug into the populations. This does not replace the terrain nodes compute terrain, it compliments it.

It does add a little time to the render, but it's not significant for a single image.
http://flickr.com/photos/njeneb/
Forget Tuesday; It's just Monday spelled with a T

_duke_

That way? If so, then it doesn't seem work.

Henry Blewer

I have a long render going... I think the compute terrain needs to be plugged into the left side of the population node.

Try re-seeding the population.

Another thing I do is use distribution shaders for the populations. I do not seem to get very good population coverage when I use a surface shader or a node in a surface shaders node tree.
http://flickr.com/photos/njeneb/
Forget Tuesday; It's just Monday spelled with a T

Tangled-Universe

The reason it doesn't work now is probably because you added displacements after the compute terrain (the fake stones are displacements).
These displacements might be so large that your population seems to be "below" the fake stones, but they're actually sitting perfectly on the terrain generated before the first compute terrain.

First try to use the last surface layer as "sit on" shader in your population. Then populate the population and see if it sits correctly. If I understood correctly you already tried this last surface shader as well and it didn't work.

If it does not work indeed, then try to add an extra compute terrain node. Do NOT attach this to your population, but to your planetshader.
Logically, select this second compute terrain as "sit on" shader and it should work.
If you see mistakes in placements, floating e.g., then adjust the gradient patch size of the compute terrain to a lower value.
The lower the value, the more rendertime added. Although this is pretty optimized by now still be careful with it.

Hope this helps.

Martin

Henry Blewer

FrankB or Martin told me to add a Compute Terrain at the end of he shaders node group. Plug this into the populations. Works great.
http://flickr.com/photos/njeneb/
Forget Tuesday; It's just Monday spelled with a T

Tangled-Universe

Quote from: njeneb on March 15, 2010, 08:04:42 AM
FrankB or Martin told me to add a Compute Terrain at the end of he shaders node group. Plug this into the populations. Works great.

Yes we tell that some times, but I'm pretty certain we don't tell to plug it into the populations alone without plugging it into the planetshader....at least, I never did :)

Just thinking about it again: what if you don't connect it to the planet. Will they be placed correctly and match the surface as well? If so, will it be faster, because the shaders do not use this compute terrain for rendering the terrain?
I think I need to make an example to test this, interesting.

Martin

Henry Blewer

It turned out to work the way I did it. The shader displacements are already calculated for the planet, which is why the shader displacements don't allow the objects to sit correctly.

I tried the connecting to the planet first. It did not seem to make a difference.
http://flickr.com/photos/njeneb/
Forget Tuesday; It's just Monday spelled with a T

Matt

#8
A second Compute Terrain or Compute Normal node is not needed to make the positions align. However, sometimes a Compute Normal node with a different gradient patch size will help if slope constraints on your density shader are not working as you expect.

The most likely cause for objects not sitting sitting correctly on the terrain is that there are additional displacements after the shader that's connected as the population's "sit on terrain" shader. The solution is to connect the same shader that plugs into the Planet. Another possibility is that your object has been accidentally moved so that its translate parameter is not 0,0,0. That would shift every single instance away from its calculated position. Another (unlikely) cause is that the object itself does not have its trunk passing through 0,0,0 when it was made, but to the best of my knowledge none of the Xfrog objects have this problem.

I haven't spoken about leaning plants on slopes yet. The instanced objects do not rotate to align with slopes, so objects which are fairly flat (perhaps a clump of grass) don't look right on steep slopes. Is this what you were seeing?

Matt
Just because milk is white doesn't mean that clouds are made of milk.

Tangled-Universe

Quote from: njeneb on March 15, 2010, 10:23:58 PM
It turned out to work the way I did it. The shader displacements are already calculated for the planet, which is why the shader displacements don't allow the objects to sit correctly.

I tried the connecting to the planet first. It did not seem to make a difference.

Thanks for checking that Henry, saves me time and good to know!

Quote from: Matt on March 16, 2010, 02:24:22 AM
I haven't spoken about leaning plants on slopes yet. The instanced objects do not rotate to align with slopes, so objects which are fairly flat (perhaps a clump of grass) don't look right on steep slopes. Is this what you were seeing?

Matt

Speaking about this Matt, do you think you can make such a function? It would look so much better.