Populator v4

[reck]

lol here's me moaning about 30 minute population times when people are having to cope with hours. But for me even having to wait half an hour is too long.

Oshayn, I suppose more precise placement of smaller populations would cut down some time, but in Ryans case even if it knocked the time down by 2/3rd's your still talking over an hour for the calculations. I hope that we can get the populations calculating at the same time soon, it seems such a waste of the cpu resource most of us have.

@Oshayn, TheBadger - With regard to my project i'm not sure what's considered "massive" for a populations. In my case the 7 populations range from 3k x 3k area up to 5k x 5k area. Is this really such a large area when you're looking out over a landscape? Most of them are distributed with a fractal breakup and then a mask is applied, maybe this adds a lot to the time?

[Oshyan]

It's not the total area alone that determines population time, it's really the total number of instances which is area times density. In your case I suspect the populations are pretty dense, even though the area is not particularly large. The calculation time is dependent on the total number of *potential* instances, in other words the number of instances there would be with no masking whatsoever, so even if you're masking your dense populations down to just a few areas in the larger population square, it's still having to test for each potential instance to see whether it should be populated. So a dense population area with a million *potential* instances but only 1 *actual* instance will, I believe, take just as long to populate as all 1 million instances would. That's why I suggest making smaller areas in separate populations, especially for dense things like grass. The differences can be much, much larger than knocking the time down by 2/3s, it could be a factor of 10 or more, depending on how heavily masked your populations are.

- Oshyan

[RArcher]

Certainly a possible solution to do it that way, but I find I am not nearly random enough to make things look realistic if I place too many specific populations myself.  I like to be surprised sometimes by where things end up because they aren't always just where I would put them.

It would be nice if it was possible that the software would first take into account the density shader/masks and then only try to populate the areas that where the trees can possibly go.

[Oshyan]

It would be nice if it was possible that the software would first take into account the density shader/masks and then only try to populate the areas that where the trees can possibly go.

I believe that's exactly what it does. But it needs to test whether an instance exists in a particular part of the population at some point, so the entire population needs to be evaluated at that time. That's my understanding anyway.

- Oshyan

[RArcher]

Right, now what I would like it to do (though I am sure there are good reasons it doesn't) would be to first take a look at the masking to determine where the populations can and cannot go and then only do the calculations for those areas it can go instead of calculating every possible area in the population bounding box regardless of whether it has been masked out or not.

[Oshyan]

Without the ability to define arbitrary population shapes, I don't see  how that's possible. It's similar to the way clouds work. Localize Clouds speeds things up because the renderer knows the clouds will exist in a finite area, it doesn't need to check the entire sky for possible clouds to render. But you have to define the shape very specifically, and that can't be done with a procedural noise function because the function itself needs to be calculated to generate the bounds. I imagine there may be ways to do this more cleverly, at present the issue exists not just with populations, but with clouds and really anything that is blended by a procedural function - you have to calculate the function to determine the coverage, and that is apparently the expensive part.

- Oshyan

[otakar]

#5 set up multiple populations' coordinates, wireframe modes, sit on surface, planet, density shader, etc. etc. with a masternode or by drag-select and right-click or...
Basically anything which saves me copy pasting tons of similar settings from one population to the other...

Population groups is what I've suggested elsewhere. Set the parameters (as above) for the group and they would propagate to the children (individual populations). Would make it so much easier to modify a busy scene (and organize its elements).

[reck]

@Oshyan I guess lots of medium to small populations instead of a few big populations are the way to go then until population calculation speed improves. One of the downsides to this is that I already have a lot of populations to manage and splitting them into even more smaller groups mean that they get harder to manage and there's more copying\pasting between populations etc.

I think the answer to this is population groups as Otakar mentioned below. Then you can group related populations together and enter settings that affect the whole group.

[paq]

Hello,

The limitation of the populator to scatter only one object at the time is really concerning when you are comming from Modo,Vray multiscatter or Vue. Maybe I miss something, but how do you avoid overlaping instances if you scatter for example 5 or 6 trees model ? Having to sample the same terrain area 6 times is also a waste of computing ressource ... but again maybe I dont really understand the process.

(that having said, it doesnt seems to prevent some guys here to create amazing image )

[Dune]

If you add a high contrast power fractal and with some merge shaders to make a set of non-overlapping masks, you can avoid overlap. There are other methods, which have been posted. The thing I am mostly concerned about is overlapping of instances within a population. I wish (I'll mention it as a feature request) there would be a minimum distance between instances to be set.
I occasionally have a flock of sheep where some Siamese twins occur 

[paq]

Hi Dune, after 2 days I only understand the method you describe, seems to be a really smart idea, I ll give a try.

[Tangled-Universe]

If you add a high contrast power fractal and with some merge shaders to make a set of non-overlapping masks, you can avoid overlap. There are other methods, which have been posted. The thing I am mostly concerned about is overlapping of instances within a population. I wish (I'll mention it as a feature request) there would be a minimum distance between instances to be set.
I occasionally have a flock of sheep where some Siamese twins occur 

Then your object spacing is simply too small. If you have models with say 2m circumference and the spacing is 1m then yes...they will intersect.
I see where you're coming from though. If you increase object spacing you end up with not enough instances to your tast and also some regularity may occur.

In the end I think the populator needs an overhaul.
It desperately needs a kind of masternode to control multiple populations at once and having a kind of collission detection coming along with that would not only be ideal, but also almost kind of necessary to have it work properly.

[Dune]

Then your object spacing is simply too small

Even if it's not too small you may get overlapping instances.

[Tangled-Universe]

Then your object spacing is simply too small

Even if it's not too small you may get overlapping instances.

That's because of the spacing variation, especially if you have it set to default 1 or even higher.
With spacing variation @ 1 you can have an instance being positioned at nearly the exact same position as its adjacent instance.
With spacing variation @ >1 you can have instances moved outside their "object space/box" into the "object space/box" from its adjacent instance.

So you can avoid this with playing with these settings, but like I said you may end up with pattern like positioning of instances, which is unwanted.

[Dune]

I know, thanks, Martin. Though I never actually used >1 variation, I might do some testing....

EDIT: Strange, with a pop of spheres the variation @0.1 has no influence, have to do some more testing.