Thanks. Is there currently any way of simulating an instance that does not have the original object at the world origin?
Also wondering if there is any way of simulating objects in a collection. Without looping through the collection and adding each convex hull as a shape, which doesn’t seem to be possible yet.
Hi Lukas, may I ask if there are any plans to include physics into posing, i.e. posing with collision, or posing with softbody etc.? I heard one of the goals of implementing physics in Geometry Nodes is to make a unified system for physics.
A note for people making videos: Please do not mention “Blender 4.3” in the title of your videos.
Users will be confused when 4.3 comes out without this. It happened with Light Linking, EEVEE Next, etc. The fact that it’s built on top 4.3 alpha it’s just because that’s the latest main codebase at the moment.
It is not clear if this branch will come out in 4.4, 4.5 LTS, or come out at all. It’s an experiment. Maybe use the word “Experimental”.
To be fair to the creator, they did mention many times that this is all experimental and that they don’t think it will be in blender 4.3, that it’s just a glimpse of what is possible. I agree with your point though, and that the video title should probably be changed.
Please note that the time step node currently uses a fixed internal step of 1/120 compared to the default 1/60. I used a smaller time step at some point in an attempt to fix a bug and haven’t changed it back yet. This would mean roughly 2x the number of steps. There are probably other settings that don’t match.
Not saying it’s actually faster (it’s a test after all), but accurately comparing the two physics implementations is not quite so straightforward.
I wrote a quick patch that allows the Instance on Points node to work with the physics bodies. This makes the simple Suzanne example a bit cleaner 
EDIT: I noticed that when Suzanne stops moving, it’s no longer active and therefore the won’t be instanced.
So it might be better to do the selection for the instancing using Body Motion State > Static and then feed it through a Not node (not sure why the Kinematic output is not working).
@LukasTonne PS: If you add me under Sign in - Blender ID - blender.org I can create a PR for your geometry-nodes-rb-component branch.
Nice, that is already looking much cleaner. How would this work for several different objects, is it looking at the point index?
I am hoping that the end game will be some sort of collection input node that will be able to handle multiple objects automagically. Imagine the typical destruction scenario with hundreds or thousands of pre fractured objects in a collection. Of course there would be no way of manually allocating instances, so there would have to be some sort of internal linking of the rigid body shape and the rendered instance.
I know this is just an experiment but just curious about some things. I tried to do a voronoi fracture with itself falling apart. I have a pre-fractured cube as a single object, I just scaled down the islands and merged by distance to make the appropriate points. Works ok, but I’m wondering if there is a way to get the collision shapes working. I tried convex hull pipping in the original geometry, but it crashes. I think it might be because it’s treating all the islands as a whole and assigning that to each point. Would there be a consideration for this? I’m using just a box shape here so it does the ol’ exploding bit since the collision shapes are intersecting
It would also be nice to not have to work on points at some point. Just packing the objects for a simulation would be fantastic as well.
I don’t understand the question tbh. Instances are not simulated directly. What is the “original object”?
I’m planning some changes to make handling collections easier.
The options for driving armature deformation with geometry nodes are very limited. I’ve done some tests with a single armature object, but it requires a ridiculous setup to get data transferred from armature to geonodes and back. This is beyond what geonodes are designed for, there isn’t currently a node system for controlling object or bone poses. I’ll post a demo at some point.
Thanks, much appreciated.
Yeah, collision shapes for this case are tricky atm. You could try a repeat zone, loop over all pieces (or just the biggest ones), generate a convex hull for a given index, and merge them all together. Not very efficient but should get the job done. In the longer term maybe some bulk conversion by mesh island or so could be added.
If for instance I have the monkey head placed at (0, 0, 4). If I then transfer this position to a point that is then used as to instance the rigid body. The head will fall to the ground, but the center of gravity is in some add position.
It will work if the monkey head used for instancing is at (0,0,0) and then the point is at (0, 0, 4).
I see. Thank you. What about Rigging Nodes? Do you think its implementation might make armature deformation with physics possible? Although they are a very distant future, and they fall under the Animation and Rigging module instead. But if I’m not mistaken, one of the goals of Everything Nodes is to make everything interactable with each other? Right now, Geometry Nodes, Material Nodes, Compositing Nodes are all separate from each other.
@LukasTonne Here you go: #2 - Allow "Instance on Points" node to instance on physics component - blender - Blender Projects
I managed to build a setup that takes a collection of meshes, turns them into rigid bodies and then simulates them. Was surprisingly easy to do! (Yes I am using my PR to make the instancing a bit easier).
Overall setup is the same as the simple one from above:
I created a node group to convert the instances to rigid bodies (using a repeat zone). Here’s that group:
And I found that using the same mass of 1 for all of them doesn’t look that great, so here is a little weak that uses the bounding box to approximate the mass a bit better:
Excuse the poor performance of my 9 year old laptop 
Lovely thing to wake up to, thanks! It’s a little McGuiver-esque but it can be done haha. I managed to get it working without using a collection as well, as I feel that’s probably the scenario that would occur most. Of course this will be a lot easier when the for each loop eventually rolls in, and should help a great deal with 9 year old laptop performance.
Since the repeat zone is only there to set up the rigid bodies before the simulation zone, it won’t have a great effect on performance. Once the simulation starts, that part of the tree is no longer evaluated
I want to make some internal changes, to better enable instancing of “physics objects”.
Currently any rigid bodies are always created as btRigidBody instances, and then moved when realizing instances (joining geometry does realize instances under the hood as well). This means only a single instance of an object with rigid bodies can be realized.
I want to try and instead create bodies as plain CustomData initially when the geometry has no physics world. Then each instance of such geometry can act as a template for actual physics data. Joining such template data with a physics world creates the actual Bullet data.
This should enable workflows where an object is created as a “physics asset”, and then realized in the simulation geometry nodes. Such assets will not yet enable dynamic handling of physics feedback, they just provide a template, but it should open up some new possibilities for authoring physics scenes.
