Floating Population

[PeanutMocha]

I read through other posts on floating populations but didn't catch on as to what's wrong with my scene.  I have a population of monkey grass that is floating just above the terrain.  If I place a single object in the scene, it sits nicely on the ground.

I have blanked out the Y altitude of the population control (which causes 0 to be inserted... not sure if that's correct), checked Sit on terrain, and note that Compute Terrain is selected as the compute surface.

Screenshots attached.  Any thoughts?

[Dune]

What if you plug it into the last surface shader? You might have some larger displacements after compute terrain. If you copy the center of the population (right click above terrain) from the terrain and paste that in the populator, the Y should have a value. In principle changing this to 0 shouldn't make a difference, although I had something similar as well, once.

[PeanutMocha]

Thanks for your reply.

I'm still more-or-less a beginner, so working with the node builder tools more than directly with the node network (I can work with the node network, just have limited skill so far).  I'm not sure exactly what you're suggesting. 

Attached a snapshot of my current network node.  Based on that, can you help me understand what I need to adjust?

[Henry Blewer]

I add a compute terrain node to the end of the shader node group. Add the compute terrain node. Connect the last shader to this. Now connect this to the population where the compute normal from the terrain group connects. I have not noticed that this adds any render time. It does the trick of getting the objects to sit on the terrain correctly, everytime.

[PeanutMocha]

I think I did what you suggest, but there's no change.  Updated node network attached.  Does it look right?

[dandelO]

The network looks fine to me, strange. Do you maybe have an unwanted displacement (or any displacement offset) in 'base colours' or in one of those 'TX' shaders that's messing up the ground after the compute terrain node? Is the object inside the object maker set to 0,0,0?

I don't think that's the problem, since you have a compute terrain after all those shaders now but it might be worth checking.
One compute terrain should be enough, though, usually it's unnecessary to need a second, the shader you want the objects to sit on top of is normally sufficient to plug into the 'terrain shader' input of the population.

[dandelO]

If all else fails, as a workaround you could negatively offset the Y value of the single object node to the height that the population is floating above the surface, it still appears to be following the terrain, just higher. But that isn't a real answer or solution to the problem.

[PeanutMocha]

OK too strange...

I renamed Planet 01 to just Planet.  The population was still referencing the (non-existent) Planet 01.

Fixing the name fixed the displacement.

[Dune]

I might make a difference that the patch size of the last compute terrain is 20, and perhaps should be set to 1. You could try. I also found that a displacement offset (before compute terrain) in one of my latests setups caused trees to float, although I haven't looked into it with a magnifying glass yet.

[AndyWelder]

And what if you change/lower the 'y' value in the object maker?

[Henry Blewer]

If you use image maps and change the y in the object maker, then they may not be in the correct position any more. I think UI image maps specifically.

[Henry Blewer]

I did a render last night which had trees floating majestically in the air. Most of the trees were located on the ground properly. The ones which were up in the air were along surface layer and child power fractal (with displacement) boundaries. The populator seems to get confused when it is asked to compute on slopes.

[Henry Blewer]

I just finished some tests. I discarded loading my default settings from the 2.2, 32 bit version. The 64 bit versions default settings do not seem to have any issues with flying trees. It's curious. The only settings I changed for my default settings were the image sizes, quality, and AA.

Re-reading the change log...