Not so much for modeling… but a chain of attribute nodes is harder to follow, than if those attributes were edited as a script. It is easier to see the logic of what is happening. Plus I think just Python can be reused with special functions from bpy.
Hi, without more context there is not much that can be done. Please share what you are trying to do with the geometry nodes. The progress of your work and the limitations you are facing (and perhaps the workaround you found).
This is the only feedback the team can handle. The team then take all into consideration when thinking about the priorities and the design decisions.
1 Like
Hi!!
I’m really interested in the “point instance in volume” feature like the old particle system with fill volume and grid fill volume, the approach that was taken right now witch consist of converting pints in volume then fill them with points is not what we’re expecting.
Depends what the end game is. I’d be as happy as the next guy to get more performance for weight painting as it is super painful to work on anything in a vfx pipeline, but if the goal is not those billion poly scenes but focused on the open movie at hand it might be sufficient.
I mean it could be improved for sure, but there’s a long list of contenders for getting more performance.
While we’re on the subject of weight painting, and I’m sure it’ll come up for geo nodes as well at some point (eventually working with bakes will become a thing as the feature set expands), it’d be neat to be able to weight paint on a mesh sequence cache looking at the state of the active frame, not just the start frame.
That’s because the volume distribution feature is not completed yet. Once mesh to volume node is added you’ll get everything you expect and maybe even something extra that you didn’t expect 
1 Like
Our team uses Blender to create reality-based rally stages for Richard Burns Rally simulator. This is basically a long road with surrounding terrain, covered by the vegetation.
Such scenery can be pretty long - the longest stage is 50km, then the total number of vegetation instances (clumps of grass, bushes, trees, …) reaches ~1M.
This is 1/6 of the whole scenery
To avoid placing all the vegetation instances manually, we currently use particle systems to batch-distribute the vegetation over the scenery (together with manual placement where more precision is needed).
We start such projects with a terrain prefab (piece of road & surrounding ground) which has some default particles-weights already pre-set, then we duplicate this piece using array&curve modifiers to get the basic ground with general vegetation quickly:
… then we adjust it as necessary using weight painting:
works smoothly in the example because the emitter is very small
The resulted stage can be seen here (to get an idea of required instances count, ground size etc.):
…or in case of a forest stage:
While particles does the job, they are far from being the ideal tool for this task, because:
- every change of the emitter (like weights update) causes all the particles are regenerated = no precise control over the result
- impossible to weight paint such large emitters due the very bad performance (we need to set the weights in Edit Mode by selecting vertices and entering a weight value)
- particles update performance (takes seconds to update / regenerate single particle system)
- we need to use custom (crappy) addon to maintain the same density regardless of the emitter size or weight-painted area
- makes edits of the ground (= emitter) very slow, need to use workarounds like using copies of the ground as emitters
- limited options for distribution, no way to avoid overlaps etc.
As recent Blender releases finally got some features we were waiting for, we are about to switch from 2.79, and so we are investigating options to improve our workflow.
GNodes seemed to be very promising replacement of our particles-based planting workflow, unfortunately the first test showed that we would face very similar performance issues like with particles (laggy weight painting, low viewport fps).
We would appreciate a lot if anybody can suggest some smooth workflow for this task (scattering large amount of instances over large ground mesh).
25 Likes
I also have something to add. Once I had discovered that the Bullet physics engine(which is a part of Blender) has special terrain(heightfield) collision algorithm in addition to that well-known as box, cone, convex mesh, etc.
So that I hope with possible intoruction of a concept of heightfield we might get appropriate effective collision shape. I expect it more effective than colliding against an arbitrary concave mesh.
So I’m up-voting for the special heightfield data type of some sort being implemented in Blender.
1 Like
This is absolutely awesome!!! 
1 Like
There is also another point I’d like to get the answer from the developers.
@dfelinto
Please, send a link if it was already answered (1041 messages on this topic =) )
A similar workflow was mentioned in the Blender Cloud video about scattering leaves on the twigs, and then, scattering those twigs on branches.
If we have a twig with a weight map, scatter leaves, then scatter twigs on the branches we get the same leaves distribution along all twigs, since it is instances.
To get more random leaves distribution we need either make more twigs with different random seeds, or convert twigs instances into real geometry, and distribute leaves on top of that.
I tried to do the whole random scattering on instanced twigs in one Geo-nodes tree, but twig’s weightmap is unavailable unless I intermediately convert it into real.
Is there any plan in the development to make attributes available at least for reading for instanced meshes?
(Sorry if my explanation is unclear, I hope images will help)
Thanks!
I assume you have tried using a second lower resolution mesh for particle placement only. Why did that not work / not good option?
I heard there was proposals of considering a math expression node, not a full blown script node yet. I think that consideration was pushed a bit to the side however. I do think that geometry nodes should only receive full blown scripting support once it warrants it and things have matured to the point most users wouldn’t need it. Right now I have a bad feeling that it would be a pandoras box of everyone building a stack of slow/unreliable solutions on top of geo nodes and rapidly turning the ecosystem into a mess of workaround scripts. Geometry nodes should probably be allowed to grow it’s roots with core nodes first IMO.
6 Likes
Heightfields are definitely a +1 for me. Performance gains would be big over arbitrary meshes. I like to edit my terrain in the same package I do my blockout in. Blender’s current terrain tools are just limited to the ANT addon, making it a core part would be wonderful. With it built on top of the geometry nodes tech that would open up a lot of cool stuff. I would love to contribute to that if a design strategy is proposed and the ball gets rolling after working on volume stuff.
3 Likes
1 Like
Yeah, that’s exactly why I started learning scripting in Blender, so I can not only model environment assets, but be able to build whole landscapes in Blender.
Blender’s current terrain tools are just limited to the ANT addon
It’s not just about generating a terrain mesh procedurally, but being able to populate it non-destructive way as much as possible. This video sums up such tools extent quite well.
With this addon I’ve been able to help building quite large landscapes for Arma series/DayZ(up to 30x30km), but only because the addon allows me to import smaller insets of terrain, edit them(sculpt, paint splat masks, populate) and then merge the changes back to the original heightmap. This approach works in 90% of use cases, but if I’d need to do something like flattening terrain under roads which cover whole map(entire terrain would have to be imported) this is then rather big performance issue.
So having performant data structure for terrain representation which goes hand in hand with Geo Nodes… oh boy that’d be so great!
4 Likes
There are other solutions for that, not only modifying the source code, and @jacqueslucke is aware of this 
I assume you have tried using a second lower resolution mesh for particle placement only. Why did that not work / not good option?
Already using this method, but it is just a workaround which helps with the performance only a small bit as I can’t make the detail lower significantly (there is still some precision needed even for the particles distribution). Also it brings up some disadvantages (extra work by creating and managing these separated emitters).
What I am looking for is some smooth workflow for scattering large amount of instances over large mesh, without such ugly workarounds we have to use now.
I am pretty sure modern HW should be capable of such task (Unreal Engine proves that).
2 Likes
Hopefully pablo can fix vcol and group performance instead? 
He did fix perfs in sculpt mode, can’t his optimization be ported toward vg and vcol?
1 Like
Hello, is there a way to add particles on the base of coordinates read from a text file? thanks
Just tried vertex colors painting of 1M mesh in 2.92 (it is same in 2.93) and compared it with 2.79.
There must be something wrong as it is as laggy as weight painting - so scattering with GNodes & vcols defined density won’t help.
In general I wish devs could focus on the Blender performance as much as on adding new features. It is difficult to take advantage of those if everything is so slow once a project gets heavier (1M mesh is nothing these days, isn’t it?).
11 Likes
Blender’s current terrain tools are just limited to the ANT addon
I will just plug this here (I am the developer)… https://iperson.github.io/tn_docs/
5 Likes