Hi everyone,
Something I've wondered about for a while is what size populations you'd typically use, and what is the largest you've used. By "size" I mean the number of instances. I'd be very interested to hear what you use. It doesn't have to be accurate, I'd just like a rough idea. Even an idea of the area and spacing would be helpful, for example 10,000m by 10,000m with 10 m spacing.
Regards,
Jo
I seldom go over 100.000 instances per pop, and mostly restricted to about 6000x6000m. For far pops I have very low poly trees. The default spacing is pretty mean (average), as for grasses it's sometimes 0.1, and solitary oaks sometimes 25.
This is pretty difficult to answer, because it's very dependant on what I'm looking for.
If I want much variation in trees/bushes then I use higher spacing values so that they mix more easily.
Do I want huge carpets of similar models then I just load 2 or 3 models max and use small spacing, quickly increasing instance numbers.
I don't think I'm very representative when it comes to these as I'm always trying to push the limits of the software and especially my machine.
I have 16GB of RAM so I like stuffing it with as many pops as possible up to the point I can just render it with the settings I have in mind.
Trees are usually in the 100s of thousands max, but only for large scale work.
Small scale stuff, which I do more often, has several 1000 trees.
Tree spacing is ~8 to 20 metres. Sparse trees around 40-50.
Bushes and the like scale accordingly, usually around ~5-10x more than trees.
Spacing of bushes is usually about half that of the trees, so 3-8 metres I remember to use the most.
With grasses I quickly have a couple of million of each grass species, usually I use 4-6 grass types.
On some occassions I use even bigger numbers, but I always try to avoid that because the populating process is still not multi-threaded :P
Spacing is typically around 0.05-0.25 (depends on model size).
My biggest population by area is ~25x25km with 8m spacing IIRC. How many instances are those, ~(25000/8)^2 = ~10M I think.
My biggest population by numbers I can't remember exactly right now.
Pretty much the same as the others. I used to have much larger pops but I've got cleverer at masking them!
The default is to have the object that your populating inside the Populator node. I prefer not to work that way. By having the object outside the populator node it can be easily re-used by several populations (not that it can't be accessed from populations internals, it's just easier to work with when it's on the top level with everything else). So when I have a scene, say a hilly one there is no point in populating stuff I can't see, for example stuff on the back of a hill. I find it better to have several populations using the same object placed so they are only populating the areas that the camera can see. Saves on memory, saves on "populating" time and each population can be set to render at a different quality depending on distance. The actual number of objects in a population will vary a considerably and is entirely dependant on need. For example a grass field close to the camera will be dense enough (probably using several populations of different models for variety), that the ground surface is almost completely obscured. The same grassy field further away will need a less dense population since the camera angle will be "flatter", looking more at the edge of the grasses rather than the top so seeing even less of the ground surface. You can use a distance shader to blend pretty seamlessly between these two kinds of population.
Quote from: jo on June 18, 2013, 10:38:00 PM
Hi everyone,
Something I've wondered about for a while is what size populations you'd typically use, and what is the largest you've used. By "size" I mean the number of instances. I'd be very interested to hear what you use. It doesn't have to be accurate, I'd just like a rough idea. Even an idea of the area and spacing would be helpful, for example 10,000m by 10,000m with 10 m spacing.
Regards,
Jo
Hi Jo, I wonder why you ask? Any feature development on you mind? ;-)
cheers
Frank
I didn't dare to ask, but wondered the same! ;D
And to answer your actual question, since I didn't read it properly first time.
Current project is using populations from 10m x10m with a density of 0.1 to 8000m x 4000 with a densities of 20 x 20 and 600 x 600 and everything in-between. 24 pops in total.
Not much help I guess
Hmmm intriguing :)
Yes I forgot to add that to my intial post...I generally use roughly 10-25 populations too.
More than 25 is rare and rather an exception.
My populations (except foreground) usually cover pretty large areas but the total number of instances is never all that high. Depending on the type of tree or the look I want I generally keep the spacing at 0.5 x 0.5 or so and then blend this area by a powerfractal to get smaller clumped areas of densely packed trees or bushes with more realistic spacing. 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.
Difficult question. I have tried going over a million instances, but that is rare. Usually it's in the tens of thousands and below. Often times only a few (<20) instances, for tree or animal clusters for example. As I learned to use the tool better I was able to reduce instance counts via masking and built in population area modifiers.
With grass I have done something like .5-.005 x2 density, over anywhere from 15meters to 500+m, on each object variation.
I think I have had to go much larger than this too, in order to get total coverage in my target areas.
The last scene I worked on, originally intended for the NWDA contest but didn't finish in time because of my real job, had the following populations (taken from the tgdcli output):
10,000 objects created by Populator "Pop wheat.tgo"
28,561 objects created by Populator "Pop cornPlant.tgo_1"
576 objects created by Populator "Pop ND01_Grass1_v6.tgo"
9 objects created by Populator "Pop tundraheather-2.tgo"
1,401,856 objects created by Populator "Pop ND01_Grass3_v5.tgo"
16 objects created by Populator "Pop Shrub02.tgo"
576 objects created by Populator "Pop Dandelion_v3.tgo"
625 objects created by Populator "Pop Weed1_v2.tgo"
32,400 objects created by Populator "Pop cornPlant.tgo_1_1"
9 objects created by Populator "Pop tundraheather-2.tgo_1"
119,025 objects created by Populator "Pop wheat.tgo_1"
256 objects created by Populator "Pop reed-4.tgo"
32 objects created by Populator "Pop reed-2.tgo"
256 objects created by Populator "Pop reed-3.tgo"
625 objects created by Populator "Pop cattail-2.tgo"
625 objects created by Populator "Pop cattail-1.tgo"
100 objects created by Populator "Pop FL34_3_Amaryllis.tgo"
36 objects created by Populator "Pop BS17a_Kanzan_Cherry.tgo"
100 objects created by Populator "Pop FL34_2_Amaryllis.tgo"
=======
1,595,683
As you can see, I used a lot of my NWDA purchases plus some free Xfrog stuff (can't wait for NWDA to be back online!)
QuoteA 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.
Quote from: jaf on June 19, 2013, 08:12:59 PM
....
As you can see, I used a lot of my NWDA purchases plus some free Xfrog stuff (can't wait for NWDA to be back online!)
That's so kind of you to say that! We're working on the comeback :-)
Frank
Quote from: RArcher on June 19, 2013, 11:38:14 AM
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.
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.
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.
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.
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.
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.
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.
QuoteOr 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.
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
Hi Ulco,
Quote from: Dune on June 20, 2013, 02:18:33 AM
QuoteA 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
Thanks for explaining that, Jo.
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.
Quote from: Dune on June 20, 2013, 02:18:33 AM
Maybe it would be faster if we could directly influence the seed, i.e. use a PF as seed.
Quote from: jo on June 25, 2013, 05:57:04 AM
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
Quote from: FlynnAD on July 07, 2013, 11:40:20 PM
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.
Quote
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
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.
Quote from: Dune on July 08, 2013, 02:07:01 AM
...
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.
I see a feature request here: "use camera angle" checkbox with camera selection field. :) (in population node)
Quote from: otakar on July 08, 2013, 02:17:56 PM
I see a feature request here: "use camera angle" checkbox with camera selection field. :) (in population node)
The populator already has an option called "clip to camera", but you can't choose which camera to clip to and it always uses the current render camera. But, again, as with density shaders, the terrain displacement needs to be sampled for every *candidate* instance to find out whether it falls within the camera's view.
Matt