Yeah, ideally this is how things would work on the engine side too, I guess. The signals could live in PhysicsBody3D just as well, and be emitted for both bodies when a RigidBody3D overlaps it.
It doesn't even sound like that breaking of a change, but I'm probably missing something.
More or less, yes, but even a frozen RigidBody3D would be doing more stuff during its state sync. Hard to compare with GDScript involved though.
By using a StaticBody3D you also avoid the clutter of all the properties that RigidBody3D brings with it, but that can be fixed in other ways as well.
extends StaticBody3D func _ready() -> void: PhysicsServer3D.body_set_mode(self, PhysicsServer3D.BODY_MODE_KINEMATIC) PhysicsServer3D.body_set_max_contacts_reported(self, 10) PhysicsServer3D.body_set_state_sync_callback(self, _on_state_sync) func _on_state_sync(state: PhysicsDirectBodyState3D) -> void: if state.get_contact_count() > 0: print("Contact!")
This might very well be the same as the rigid body workaround you've tried already, but if you're willing to accept the slight performance hit of having your static body be an always awake kinematic body instead then this should also work.
Yeah, that's a good point.
I guess I see it as a quick "just make it work" button that can handle shearing and all that, without having to deal with the potentially quirky output from proper convex decomposition, but maybe the usefulness of that is more limited than I imagine.
Other engines (like Unreal) seem to implicitly generate the convex hull approximation for you at runtime, last I checked, which seems like it must surely be frustrating in other ways instead, but maybe that is the more pragmatic approach, I don't know.
That in combination with some editor feature to bake oddly scaled shapes into convex hull approximations would go a long way I think, but there's probably an argument for having something like what your addon does alongside that as well, when you absolutely want the primitive shapes.
I really need to get around to making a pull request to get rid of that error at the bottom when working in the editor, in favor of having the node configuration warning reflect the actual limitations when using Jolt (which can handle non-uniform and negative scaling within reason).
I don't know anything about the PS5, but generally speaking, would you be able to track down multi-threading bugs with this, like race conditions and such, or would that still be at the whims of the OS scheduler and thus be non-deterministic?
#Godot 4.6 is out, and all about your flow!
This release puts you and your workflow first with a new theme, flexible docks, and dozens of UX improvements. And Jolt Physics by default, revamped IK, better reflections, and more.
Less wrestling with UI. More making games.
godotengine.org/releases/4.6
A sneak peak of what I've been working on: A strand based hair system for Jolt Physics (WIP): youtu.be/Rl19G0c003o
The Godot 2025 showreel is out! We're so grateful for every submission, vote, and support from our community 💙
www.youtube.com/watch?v=7ZwE...
#GodotEngine 4.5 has finally arrived! 🎉
With this new release, we made meticulous efforts in order to amplify what is possible to do with our engine, guided by our goal of making gaming and game development for everyone!
godotengine.org/releases/4.5/
Having once tried to implement hot-reloading for MSVC, by hijacking the jump thunks used by their incremental linking, static variables was indeed what (pretty quickly) made me throw in the towel, so I'm glad it seems to be as messy as I imagined it would be.
Note that since the extension now has to live alongside the built-in Jolt module in Godot 4.4, I've renamed both the engine and the project settings category, to hopefully make things less ambiguous.
Both of those should migrate automatically, so shouldn't require any action in most cases.
For anyone still in need of the few extra features that weren't carried over to Godot 4.4's built-in Jolt module, or who might still be using Godot 4.3, version 0.15.0 of the extension is out now, which brings with it some bug fixes as well.
github.com/godot-jolt/g...
#GodotEngine
There might be some explanation for needing that, but odd discrepancies between the two physics engines like that should generally be considered bugs, so should still be reported.
I haven't tried it myself, but it does sound like a bug of some sort.
If you're able to, I'd appreciate if you reported this as an issue to Godot's GitHub repository, ideally with a minimal repro project as well.
Not detected in what way? When listening to the body_entered signals of either body?
#GodotEngine 4.4 is finally here! 🚀
Look forward to plenty of quality of life improvements hidden within this release. Faster load speeds, reduced stutter, streamlined processes, and more!
godotengine.org/releases/4.4/
If you're able to construct some kind of repro for it (even if it's not 100% reproducible) it would be great if you reported this issue on Godot's GitHub.
It took a Brackeys video for me to realize that I had messed up the packaging of the now three months old release of Godot Jolt, resulting in it ending up in the root project folder when installed from the editor, as opposed to the addons folder. 🫠
Still neat to see it mentioned though!
You'll likely run into problems when running the current release of the extension in Godot 4.4, as there are class name collisions between the two implementations. I need to put out a new release that is explicitly compatible with Godot 4.4.
You can always compare against Godot Physics instead.
They should in theory be largely the same, but I submitted a couple of scary optimizations for the Godot module over the holidays that seem to have caused some regressions, so keep an eye out for any issues.
I'm not involved in those decisions myself, but assuming everything goes well with Jolt then it will most likely become the default, and Godot's own 3D physics engine would be deprecated some time after that.
I haven't taken the time to profile them both side-by-side, but I wouldn't expect a massive difference. The GDExtension bindings didn't add that much overhead last I checked.
What might matter is the compiler used, as Clang seemed to do better at optimizing Jolt, whereas Godot compiles with GCC.
It definitely wouldn't have gotten to this point without the help from @jrouwe.bsky.social, so a big thank you for his continued support.
Also, thank you to everyone who took the time to try out the Godot Jolt extension these past two years, especially the ones who reported issues.
I'm very happy to report that Godot just merged the integration of Jolt Physics, as an experimental alternative to Godot's own 3D physics engine.
github.com/godotengine/...
#GodotEngine
Fair enough! 🙂 It's almost certainly 0.12.0 then.
Congratulations on all the success with PGRC in general. I've been meaning to pick it up and try it for myself. I was a big fan of both JellyCar and Where's My Water back in the day.
Congratulations! It seems like the perfect title for something like the Steam Deck.
I'm a little bit curious what version of Godot Jolt you ended up shipping with, if you happen to know?
Don't forget @jrouwe.bsky.social as well. 🙂 The work that happens on the extension side is very much dwarfed by his work on the Jolt side of things, often to accommodate for the Godot extension.
