Damn you’re always faster. Anyway, exciting right? I long for the day we don’t have to get out of Blender for making the simplest of dynamics. looks like it might happen during my lifetime after all
6 Likes
Blender has technically had rigidbody and even softbody dynamics since its early days.
Yes, it was mediocre stuff by today’s standards and had limits in their use cases, but it did sometimes come through for me in cases like block buildings being smashed for still images (ie. better than nothing at least even if it was useless for most production).
This begs the question of how granular should nodes be exactly? should simulation solvers like pbd/xpbd and the like be implemented with nodes? could it even? just entertaining a thought
finally some work being done for physics
3 Likes
Will the shader nodes also get bundles? I ask because complex node setups can get pretty messy there as well (improvements in higher-level shading for Cycles has improved the situation somewhat, but you can still have tons of nodes).
The same for compositor nodes, some of the posted color correction setups using AgX as a base are getting pretty complex.
Pretty much all sorts of simulation solvers work in different stages. Having those stages as nodes would allow for lots of flexibility, likely even enough.
I am not sure if going lower level than that would make sense, because it would require that all the typical simulation algorithms could be implemented using Geometry Nodes. There is a planned list feature, but I would be surprised if it was powerful enough to for instance allow all sorts of space partitioning algorithms.
1 Like
I see. I’m not too familiar with physics solvers. What I gather from Jacques’ devtalk post is the xpbd solver is going to be implemented as a node group indeed. I think this is fantastic
At some point in the post he mentions “internal sockets” for kdtree & bvh, I think that means “not exposed to the user” but who knows?
Yes ! from the blog post :
We will try and implement as much of this as possible using generic geometry nodes. Some parts like collision detection and constraint grouping may require new built-in nodes for performance reasons. This will be decided when we get there.
1 Like
Is it only me or… there’s a lot of complexities introduced in there?
“bundles” “closures” “context attributes” “field context zone”
Geonode isn’t difficult enough? 
I’ve been using geometry node since the very beginning and have decent technical knowledge, and even with the explanations, I don’t understand any of these concepts and why they would be useful.
Quite afraid they are bulding a Rube Goldberg machine here
5 Likes
Absolutely
That’s the way to go in my view as well. There is no need (at least not now) to turn Geometry Nodes into a powerful programming language. Add what is needed.
Some time ago Joseph started to experiment with a boids (Geo?Boids: Better Boids Simulation with [Geometry Nodes AND/OR scripting]). That’s a great application of Geometry Nodes in my view, except that the performance can’t be great if there are many boids.
If the new nodes are made to be flexible enough, they could be used to massively improve the performance for that boid project.
2 Likes
I would love if I could move forward with this project with just geonodes, I ended up abandoning the geonodes route and focusing on scripting instead because geonodes just didn’t have what I needed. Unfortunately, running simulations through Python is crazy slow- <1 FPS before baking. It would be a dream come true to be able to finish that project in native C++ geonodes 
(Good looking out, thanks for the tag!)
2 Likes
Did you also read the blog post (https://code.blender.org/2024/11/geometry-nodes-workshop-october-2024/)? For each of those concepts, there is a good explanation.
I did, i don’t see the need for any of these new concepts to exist at the first place. Looks overcomplicated and over-engineered
3 Likes
From what I can see, there are 2 or maybe 3 which would have been useful to me in the past. So I guess I disagree with you.
Edit: To be more specific
- Bundles: I remember having to use 3 objects all over a geometry nodes setup. It would have been really nice to have bundles for that, which would likely have helped to not confuse the order of those objects. And a lot less dragging over long distances
- Lists: That’s literally one of my most anticipated features (but I didn’t even expect it to be a planned feature). There were so many cases where I had to compute an intermediate result which did not have the same number of e.g. points as the Geometry I have been dealing with.
- Field Context Zone: As far as I am understanding it, I would likely “abuse” this for debugging a lot. If something produces weird results, this might help to isolate individual results.
3 Likes
Could you explain which ones? 
Sorry, I figured it would make sense to be more specific and started to edit my post, without realizing you replied.
Those new concepts are simplifications of node tree allowing to create more complicated powerful node tree.
Bundles are basically similar to Reroute nodes, but supporting multiple different data connections as one. So instead of having 3 long parallel connections lines (a green one for geometry, a blue for vector, a grey one for numerical value used as factor), node tree only shows one.
Closures are similar to NodeGroups, but you are not adding it to NodeGroup list .
So, if you need equivalent of a NodeGroup in a NodeGroup ; you will end-up with only one NodeGroup item in Add > Group menu instead of two.
That simplifies that menu, getting longer and longer at each use of another NodeGroup asset.
Context Inputs is about the same need to reduce use of NodeGroups. In linked video example, we can see Erindale using NodeGroups without inputs, as a way to produce drivers common to multiple node trees. Because a value inside a NodeGroup is common to all reuse of the NodeGroup.
So, the idea is just to have a way to have inputs common to several node trees.
When user will tweak it in one node tree ; all the other node trees are evaluating the modification. And there is no more need to enter NodeGroup to do the tweaking, value will be directly accessible.
It is clearly mentioned that Field Context Zone should replace several nodes ( Sample Index, Evaluate at Index and Attribute Statistics nodes).
And if you have used zones (Repeat Zone, For Each Element Zone), you should have understood, that they are avoiding to duplicate several times same part of nodetree. That will be the case with the For Each Geometry Zone, too.
So, at the end, all of that should reduce amount of nodes necessary, improve readability. It should help to produce complex simulations by simplifying their readability.
9 Likes
Good news, they aren’t removing nodegroups, just proposing adding more utility for advanced users.
Geonodes is allowed to be complex, especially for optional advanced features. If you prefer to have individual connections rather than using bundles, you can do that.
Geonodes is going to add more and more features as time goes on. This is a good thing. I do not want to encourage the developers to take away the option for advanced users to have tools that solve advanced problems just because they might confuse less advanced users.
I’d hate to see GN turn into this;
its inevitable i believe. i see geometry nodes as a system built by developers, for developers… the more powerful it becomes, the more complex it will be.
blender is on its way to become a development platform 
There should be a way to implement them elegantly and in an user friendly manner.