I will definitely be buying this add-on too! Blender is incredible but has always been pretty weak in the area of particle systems and that’s one reason why people stick with 3DS Max and ForestPack for architectural design. This could be the start to a change in that and I look forward to seeing how the Blender developers react to this add-on. I just hope they change the underlying particle system problems that you’ve found so far so you aren’t so limited in what you can achieve. When the Blender developers see what you’ve done I think that it will put a fire under their butt to make up for the weaknesses of the present particle system so you can take this even further!
Blender is already absolutely incredible so this will be the next step on the path to taking over the DCC market for Blender. What you’ve done so far is nothing short of amazing and I look forward to watching how this develops.
I’ve just been doing some quick testing of the beta, and it’s already so good. I’ll try to put some renders up later, but so far this is the easiest tool for scattering in Blender that I’ve used.
To everyone testing out scatter right now.
An error message will probably pop when you are testing the « Demo » biomes.
This error message is totally harmless and I just fixed it. It was just an error when Getting back to user preset, as biomes will loads their own presets in the preset editor then try to te-use original preset
If you guys could test the preset And biome creation process when you have time, it could be cool
Hello, I am french architect and visualizer trying ti switch to Blender.
I followed this thread since beginning but finally decided today to register to BA forum.
Keep up your amazing work, we are an army behind you!
If you need extra testers let me know, me and friend of me doing visualization are just diving into Blender!
Thanks, I am looking after it for a few weeks but for the moment I keep modeling with Sketchup because I am ultrafast with it.
But let’s keep talking about Scatter here
The Tiger pattern gives some design first.
The resulting scatter has to much overlap.
Reducing density results in lots of rest self intersection or big holes there where forest should be.
So there is a nature phenomenon.
Tree crown shyness – a photogenic phenomenon in which the crowns of fully grown trees do not touch each other. This looks like a Vonroi pattern. In Blender we have an procedural Vonroi texture generator included.
So when we use Groove3D we could cut with Vonroi Structures the trees or we let them grow in Vonroi Voxel Volumes. Resulting in many individual trees.) Thats not the way.
But the other way around. Could a procedural Vonroi texture be used to generate the scatter from trees on the ground?
By design there would be less overlap.
Just thinking on a 4k map.
Your terrain is 1024m.
So you have 1pixel for 0.25cm.
You generate a procedural Vonroi with parameters that every cell is around 4m.
So when you have trees on your scatter layer who have a diameter from roughly 4m you should be able to filter all trees out .
So no tree will reach roughly the other one.
With some move on the slider you could bring them closer together or give more distance. But there should be less overlap.
With the overlayed tiger pattern you generate the design afterwards.
Here some great parametric trees for umme. Also great is the automatic LOD generation.
Simply generate an AutoLOD tree and push the group to the converted particle scatter groups.
My original meadow had much more species, and the falloff on the path was easier, but I’m quite happy with effect of only one species with… alot of instances.
It took 10GB to render, with more species it would take 100GB I guess. The reason is that there are many parent particles, with less children that I would do by hand.
heck ? that’s really really enormous.
not normal at all.
a scene like that should be 200mo maximum…
what is the cause of this ? the use of children you said ? Witouth any child’s what is the vram ?
did you apply the particle System ? Did you use an huge hdri ? Did you use micro displacement ?
It’s because of paricles. If you don’t use a lot of children - the ram usage jumps like that. I didn’t have this problem on 2.79.
Had similar problem with previous renders with Graswald, after unchecking ‘disable children optimization’ the ram usage was acceptable (I have 32gb).
I tried with normal settings and using children particles, without any noticeable difference in memory usage. Using children did, however, seem to speed it up by 25 seconds. I’ll try and do some more tests, also with the Graswald assets and see how big a difference it makes with those.