What size populations do you typically use?

[cyphyr]

A big issue with this approach is that it takes forever to calculate since the entire 10k x 10k area is sampled at 0.5 x 0.5 even though the amount of actual instances is low.

... this is my reason for using multiple smaller populations (but using the same model so it only needs to be loaded once) only covering the areas that the camera can see,  ie: not behind hills in line of sight. Fiddly to set up but a real time saver in the long run.

[Dune]

Smart indeed. What would be very nice is a mask that masks out everything not being seen by camera, with a little extra to still see tree tops from just over the hill. Must be doable... let's think. Only smart for stills.

[cyphyr]

One should be able to create such a mask, possibly a light source at the camera's position and a plan y render to catch the shadowed areas. However this still uses a massive area of population and even those areas that end up being masked still have to be calculated. Of course the advantage to using multiple populations over a single one is lost on flat terrains where there are no hills/mountains to hide individual objects.

[Tangled-Universe]

Or project a white image through your render camera, set terrain black and render it from top down without shadows and lighting.
The use that render as plan Y projected mask.
On top of that you can also use "clip to camera" to make sure nothing outside the frustum is generated.

[cyphyr]

The trouble with any approach that uses a single population is that every part of that population is still calculated, and this is the time consuming part. For each part of the population (as I understand it) a calculation is made to see if that object either falls outside the camera frustum or is masked or not) so there is minimal time saving.

[Henry Blewer]

I have used 10,000 x 10,000 many times for trees. If the pop needs to be tightly packed together, I use smaller areas. I start with the larger plants first. This way I can hide the areas not covered by the small populations.

[RArcher]

That is a very smart way to do things Richard.  The only problem I have with it besides the extra additional setup time is the trouble of being random.  I love the procedural nature of having things fall wherever instead of me dictating exactly where things go.  If I have to pick exactly where to put things I end up being way too structured.

[Dune]

Or project a white image through your render camera, set terrain black and render it from top down without shadows and lighting.
The use that render as plan Y projected mask.

I've done that for masking out water (in the early days), but the problem is you have to make that mask first. It would be good to have it calculated at render time, and being an integral part of the seed of the pop in stead of an extra mask (I imagine the seed of a pop being a fractal). But maybe that's impossible.

[jo]

Thanks for the feedback everyone. Still interested from hearing from more people about what size populations they use, even if it's only a rough idea.

Regards,

Jo

[jo]

Hi Ulco,

A big issue with this approach is that it takes forever to calculate since the entire 10k x 10k area is sampled at 0.5 x 0.5 even though the amount of actual instances is low.

Maybe it would be faster if we could directly influence the seed, i.e. use a PF as seed.

The seed doesn't work like that. The seed value is used to initialise the random number generator which is used to randomise the positions and orientations etc. of the population instances. It isn't used to control whether an instance appears or not. That is entirely down to the density shader (not counting clipping to the camera).

Regards,

Jo

[Dune]

Thanks for explaining that, Jo.

[choronr]

On a current project, tried to get a small population to fall in the foreground of the scene (a negative -147 Y in the foreground area). Painted shader didn't work; neither did the distribution shader. Tried without either and it worked; but, the pop was falling in the work area (too far away). Finally, changed the a and b areas from 2000 x 2000 to 3000 x 75 ...and, it worked! Now I'm getting perfect coverage on the intended area.

[FlynnAD]

Maybe it would be faster if we could directly influence the seed, i.e. use a PF as seed.

The seed doesn't work like that. The seed value is used to initialise the random number generator which is used to randomise the positions and orientations etc. of the population instances. It isn't used to control whether an instance appears or not. That is entirely down to the density shader (not counting clipping to the camera).

To rephrase what I believe is Ulco's intention: it would be faster (theoretically) if the PF was loaded first, then the populator tossed instances within that PF, rather than the populator loading a vast area first, tossing in all instances in a full xz grid, then cropping the instances out by the PF. The first theoretical method would eliminate Ryan Archer's time-consuming issue but still give him the randomness of the PF. There would be no cropping of instances necessary because the PF was loaded before the populator, so all instances are where the user wants them. The populator could still have its bounding box; for example, load a PF first (wraps around the whole planet), then load the populator with its area limitations (thereby masking the PF so you don't instance an entire planet), then fill the instances.

-Matt

[Matt]

To rephrase what I believe is Ulco's intention: it would be faster (theoretically) if the PF was loaded first, then the populator tossed instances within that PF, rather than the populator loading a vast area first, tossing in all instances in a full xz grid, then cropping the instances out by the PF. The first theoretical method would eliminate Ryan Archer's time-consuming issue but still give him the randomness of the PF.

Terragen already uses the first method. Unfortunately the density (distribution) shaders need to be sampled at each candidate location where there might be an instance before the decision can be made whether to add a particular instance. You can't avoid sampling the shaders if you need to test whether to put an instance at some place. Not only that, we want to allow distribution shaders to be based on altitude, so the terrain displacement needs to be calculated at each candidate location before the distribution shaders are sampled. The population has an area of candidate instances. You decide what that area is. Then the populator decides which of those candidates become real instances by sampling the distribution shaders.

There would be no cropping of instances necessary because the PF was loaded before the populator, so all instances are where the user wants them.

Careful selection of where you want to populate still saves calculation time because it reduces the areas that you need to sample distribution shaders.

Matt

[Dune]

Thanks for bringing it up again, Matt (that was my idea sort of indeed), and thanks for the explanation why it cannot be done, Matt.

So it's better to have some small populations (using the same object), than one large area. And what I always do, is place the pop center from a top view a certain distance in front of the camera, taking the size in consideration, and then changing the angle of the pop to the same as the camera's angle. Doing it so that the lower bounding box' line is near the camera's location. That makes the perfect smallest bounding box.