Is it just me or does this start to feel a bit like an automated way of doing something much like the effect on the main character for Project Gold.
Likely still a long way to go, but adding some sort of ‘art direction’ type controls and one could in theory end up with much the same result without having to hand rig and animate every ‘fracture’.
I used the nice workaround from @filedescriptor and changed it to work in the older buildbot build. Added a second collection with heavier objects to fall onto a 500 piece sleeping shattered box.
I couldn’t work out constraints, so all of the pieces get triggered at once. However, I was able to make any pieces below a certain height be static bodies, which really shows the power of the nodal workflow. This scene was very crash prone but I managed to get a render out.
The sim speed was fine…pretty much realtime to sim it on my basic ryzen 5000 laptop.
@LukasTonne im pretty impressed with the results and the easy implementation.
Im not a programmer, but how diffuicult would a OpenCL implementation be in the future. Or are there better ways to get this to work on the GPU allready?
Nice test. Do you know why did the fracture start before the collision even happened? It feels that the collision box is not matching the object very well.
The fracturing isn’t done as part of the modifier, but pre-made from what I can tell. It’s triggering the shards to be active as soon as one of the objects hits. @jamez Correct me if I’m wrong!
@dfelinto thanks. All shards are being triggered at once, as soon as one of the shards is hit. Most likely the best way to do it in future would be to use constraints that link all shards. Then the constraint would be broken by a direct collision.
I will be interested to try this once the branch has matured. @filedescriptor all of the shards below a certain height as made to be static bodies, the rest are all active from the start.
Nice test 
I think @dfelinto was referring to the fact that the shards start moving the frame before the first object (the left ball) hits, which is intriguing.
Yes, you are quite right that does happen. Not sure if it is the convex shape being a bit off, or the sphere triggering a collision a frame or so early? Could also be a substeps issue.
Would a dev kindly ‘@blender-bot package’ for us again?
It seems alot has been done since the last build from early July and Im eager to test. Thanks!
done
Done, wait 1-2 hours and new builds will be available
Quick note: i’ve been refactoring a lot of stuff in a separate branch. Will merge all that when things are functional again.
I’ve run into an issue with two possible solutions and can’t quite decide which is better.
There is a set of rigid body properties that are intricately connected, namely mass, collision shape, and static/kinematic motion type options.
These are internal requirements in Bullet, but the equivalent geometry attributes don’t necessarily have to follow the same rules. There is an advantage to keeping attributes completely independent from each other and rules for these properties would only be applied to the internal Bullet data.
Allowing any combination of shape, mass, and motion type makes it easier to construct bodies since it doesn’t matter in which order attributes are defined. Otherwise changes to one property can override changes to another property, which could be difficult to understand.
On the other hand having no rules at all can lead to non-sensical combinations, like a static body with non-zero mass. IMO that is still preferable.
On the user level, easy to understand is more important. If there is a static body, the mass as defined by the user should simply be ignored (and internally set to 0). Predictable results are very important and the order in which attributes are defined should not matter at all. To users, those kinds of Bullet internals should not be relevant.
The risk this might become a time sink for users is way too high in my opinion.
Trying to make things ‘idiot-proof’ in my opinion (outside of making sure Blender does not crash) would be a huge waste of time that could otherwise be spent getting this system polished and into main. You can already do nonsensical things with the existing nodes if you seek them and the worst that happens is that nothing changes. The whole idea of “Blender for dummies” is not going to happen, there will still be a learning curve even with artist-friendly designs like Fields.
The best the team can do is make do on their promise to eventually ship ready-made node group assets for things beyond hair (which users can potentially use as a starting point for more complex setups, since it is already established that they work).
If you don’t mind, out of curiosity are these questions specific to Bullet? or would they also arise if you were working with a different library?
The specific problem i’m struggling with is that some property changes of rigid bodies (collision shape, mass, ‘static’ flag) require a very specific update order. It’s important to remove bodies from the simulation before changing between static and dynamic motion, but also don’t want to constantly add and remove bodies from the world if unnecessary. I’m using a lazy-init approach, where changes to these properties can remove a body from the world if the motion type changes, but it only gets added back after all updates have been done. On a more general level Bullet “documentation” consists mostly of disconnected forum posts with varying levels of expertise, makes it hard to determine what’s valid and what isn’t. I’m adding a ton of tests though to have a reliable baseline.
It’s coming back to life, slowly. I’ve started a new package build for the latest version (link).
Now i can finally use the instancing feature i’ve been working towards: Objects can generate physics geometry, and the Realize Instances node handles makes correct copies of the rigid body templates. This allows me to reproduce some of the conventional object-based workflow for constructing rigid bodies and constraints.
Demo file: https://lukastonne.info/blender/rigid_body_nodes/simple_physics_objects.blend
This is by no means the only way to create rigid body simulation setups, but i think it’s always a good idea that a new system can do what the old system did. Obviously this is not a complete replacement yet, but it offers some new possibilities.
jolt? ///////////////////////////////////////////////
Something to note on this, I believe Jolt is the way to go since even the creator of Bullet has been recommending it over it for two years now, and it only got better since.
https://x.com/erwincoumans/status/1496513233146068992
https://x.com/erwincoumans/status/1605055328512462850
https://x.com/erwincoumans/status/1804245477619102194
How many people would use this in robotics? Maybe supporting both physics engines for the time being could be optimal, since I believe the ~x6 times speedup Jolt provided in some stress tests while supposedly solving more edge cases, overall seems more future proof.
I do hope the devs consider jolt… been suggesting it for a few months now without much interest but it’s interesting to see Godot implementing it as their go to solver. 6 times faster? can you share documentation? I’m curious if having a faster and more accurate solver is something blender devs are interested in or if for now they just want to recreate current legacy (outdated solver) in geo nodes.
