It look like rotation doesn’t work in this build.
1 Like
You are right, rotation doesn’t work out of the box. The reason turns out to be attribute initialization: Blender’s attribute system initializes attributes to zero, when the default should be something else. In this case the Local Inertia vector of the body gets set to zero and that effectively stops all rotation. This should work automatically in the future, but may require some core changes ([tentative PR[(#121659 - WIP: Fallback values for attributes - blender - Blender Projects)). For now i have added a node to compute moment of inertia and set it up manually, new test files soon.
6 Likes
great, tnahks. i’ll test this approach!
few more questions. can this new system handle sequential instancing of rigid body objects? for example - +1 instance each frame. it looks like it catch initial instance amount at first frame, and after this it doesn’t react to new points
in Animation Nodes it’s very easy to do, i attach video example
it’s very famous motion graphics effect, so i hope it can be done in new system.
2 Likes
For those interested: here’s a branch with basic Jolt Physics library linking:
It includes the Jolt library in blender/extern but also has a WITH_SYSTEM_JOLT option to use a system library or local build. This branch only has a simple node atm that runs the Jolt “Hello World” example, no connection to the Bullet branch yet. I plan on refactoring a few more things before starting to actually use Jolt.
30 Likes
I’m tinkering with Jolt integration, and i want to get technical feedback on attribute design. I have 2 kinds of attributes:
- Directly stored attributes that read/write straight to engine data (Jolt/Bullet bodies and constraints)
- Indirect attributes that are stored in customdata primarily and then update engine data afterwards.
Example: “mass” is not stored directly by the engine but only the inverse mass (1/m) is actually stored on rigid bodies. I don’t want to do divisions back-and-forth all the time and lose accuracy so customdata storesmassas a “human-readable” attribute and after changes the actualinverse_massgets updated.
Question: to limit costly updates to only those bodies whose attributes are changed, does it make sense to store maybe an IndexMask for changed elements? I already have atomic cache flags for some things that need updates after writing to customdata (the usual tag → ensure pattern) but that always requires a full update, which is not nice for physics engines.
9 Likes
Discussed on the chat: Generally valid idea, but best store update flags as a (hidden) attribute themselves. IndexMask might not be suitable for persistent storage (use linear allocator). Using an attribute for this also makes sure flags get propagated correctly when topology changes (adding/removing bodies).
So i’m going to add one or more “.needs_update” boolean custom data attributes and pass those along with the actual data for deferred updates.
4 Likes
I would advocate for not storing these as attributes actually, I’m not sure that’s what Iliya meant in chat. Attributes are designed for user-editable data. So storing mass as an attribute makes sense, but internal data used for updates should be stored outside of the attribute system I think. For example, the various derived mesh caches like triangulation and normals are stored separately.
My main meant was in old direction about user-made-physics. I mean that active-bodys info also can be an optimization which is can be done by user in user-made-physics, so there is no point to hide this from built-in, if you want to move forward with this.
That’s a good point. Keeping these flags strictly internal (rather than just hiding them) would make it less error-prone. It doesn’t make a huge difference in complexity.
I am hoping to start following the development of this new physics system in blender. is there a place to reference and look at visuals, see tests, and look at experiments relating to the development of the new system?
There’s a work-in-progress PR here.
This is very much in flux, most of the info there is outdated to some degree. The branch is still a side project atm. I’m mostly working on the Grease Pencil 3 project currently, we have the 4.3 beta deadline coming up, so i’m just doing physics things when i have time.
7 Likes
awesome are there any visuals, tests or examples that show the work in progress.
no, there are no visuals, tests, or experiments to view. #development
The branch now uses Jolt as the physics engine.
The PR description now has more in-depth info about the integration design and also a demo file. This also serves as a baseline for what can be expected to work (in addition to automated tests).
Package build is proving a bit difficult because of conflicts when building Jolt as part of the extern/ folder. This should become a lot easier once it becomes part of the shipped libraries.
20 Likes
Could be that you still have an older version of the build. Check the build date in Blender. It should be from today.
EDIT: Looks like the windows build is still failing (like Lukas mentioned).
Did you download the windows version? Because that one failed to build like I mentioned.
Ah, yes it’s the windows version. I thought it was just causing it to take very long, but I see it’s actually failing.
I posted a fix in the PR, it’s just cmake being difficult we should be able to get this to build even from extern/
5 Likes