Recognize "Godot Jolt" (Jolt Physics) as an officially endorsed add-on for 3D physics

[adamscott]

Describe the project you are working on

Godot Engine

Describe the problem or limitation you are having in your project

Maintaining a 3D physics engine is hard. Especially when you implement it from scratch.

Implementing a new engine was needed. In Godot 3.x, Godot used to handle it's physics with the Bullet physics engine, but too many issues riddled the general purpose engine, enough to be game breaking. To address that issue, a developer was hired to overhaul the Godot Physics engines, both 2D and 3D. Unfortunately, this developer is not available anymore.

Since then, Godot Physics is currently in a precarious situation. The few current maintainers sure are competent and diligent, but fixing physics engine issues requires deep physics and mathematics knowledge. Both fields that aren't easy nor simple.

As @reduz said on Twitter recently:

As you know, we had to patch up and use our own physics engine for Godot 4 in order to be able to release it, as there were bugs that just couldn't be solved on the Bullet side, but this still is too complex and we just don' t have the resources to maintain it properly.
— @reduzio

So the problem or limitation the project is having is not having enough resources (including maintainers wise) to maintain a fully fledged 3D physics engine.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Jolt Physics is a physics engine created by Jorrit Rouwe (@jrouwe). It was first launched on January 23rd, 2022, but the engine was already known for being behind Horizon Forbidden West, a game by Guerrilla Games.

In constrast of Bullet Physics, it is a physics engine built up entirely from scratch with video games in mind. So it is built to handle interactivity and large worlds.

Unfortunately, the engine is not yet at feature parity with Godot Physics. But again, Godot Physics as game breaking issues that need to be fixed, if they are going to be fixed at all.

@jrouwe is actively working to add new features to the engine, such as soft bodies. Features are even being added with Godot in mind.

---

Enter Godot Jolt.

Since several months, Mikael Hermansson (@mihe) is working (successfully) to port Jolt to Godot with his GDExtension. The results are very interesting. Since last May, users can download and use Jolt in their games. Since then, numerous updates has been made and the proof has been made that Jolt could be potentially considered for Godot's physics engine needs.

---

Integrating Jolt Physics to the Godot Engine, by extension Godot Jolt, would serve two purposes:

• offering users the state of the art of physics engines;
• solving our lack of resources to handle deep physics related issues.

By recognizing Godot Jolt as an officially endorsed add-on, we could battle test Jolt Physics, Godot Jolt and GDExtension.

Then, if everything goes well, we could eventually make Jolt Physics the default engine. But there's a lot of work to do to attain that level.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Ideally, it would be integrated to the engine as an official add-on following this proposal.

But this proposal is essentially about the recognition of the add-on/engine.

flowchart TD
    USER[User]
    GODOT(((Godot Engine)))

    subgraph ADDONS[Official addons]
        JOLT{{Godot Jolt}}
    end

    GODOT -.->|Promotes| ADDONS

    GODOT -->|Download| JOLT
    USER -->|Use| GODOT

Loading

If this enhancement will not be used often, can it be worked around with a few lines of script?

One does not simply maintain a physics engine with a few lines of script.

Is there a reason why this should be core and not an add-on in the asset library?

Jolt Physics and Godot Jolt are destined to be more than only be a simple add-on in the asset library.

[mihe]

Seeing as how there have been murmurs about this for a few weeks now, I guess this is as good of a place as any to express how flattered I am for this to be considered. It's been a staggering amount of (mostly full-time) work to get to this point, as part of a longer hiatus of mine, and while Godot Jolt isn't at feature-parity with Godot Physics just yet, it makes me very happy to see all that work being recognized in some capacity.

As mentioned elsewhere, I want to underline how instrumental @jrouwe has been in getting Godot Jolt to this point as well. While I may have started this project with a somewhat naive view of how this could be achieved, it's clear in hindsight that this project would have been largely dead in the water (or at least severely hampered) if not for his generous support over the past few months.

With that said, I think it's relevant to bring up that I'm by no means a physics programmer, nor someone who typically deals with physics engines. I'm also not particularly capable with physics or math in general. I hope this helps prove the point that creating and maintaining bindings to an existing physics engine results in a significantly lower barrier-to-entry for contributors compared to further developing something like Godot Physics, regardless of how primitive it may be in comparison to other physics engines. As such, I'd be happy to help steer Godot towards the proposed direction/outcome in whatever way I can.

I'd also like to bring up some of the discrepancies/compromises that Godot Jolt brings with it, which I think are important to highlight when considering this proposal and its potential future outcome, but I have to cut this short for now and will try to expand on this at a later point instead.

[yosoyfreeman]

I have no feelings one way or the other. I don't know about physics, just about usage and user experience, so i would like to ask what you people who actually know thing about this topics.

• If this is recommended as an official addon and seem like, in the long term, it could provide more advanced tech that godot physics, would that not imply a decrease activity on the development of the Godot physics engine?

• If that is the case, as is my understanding that people deep in physics are only a few, how could this impact on the development of the integrated physics?

• If the people who is currently working on godot physics eventually find that jolt is in fact a better option, and that leads to provide Godot with a limited or unmaintained physics engine, does it not make more sense to put this into the engine by default like Bullet was?

• I remember when we were talking about the Godot physics issues that two points were often pointed out: That using a library was easier to implement basic functions, but that it requires a bigger understanding to debug issues while implementing more advances features. This was notorious in move and slide. The other was that physics engines with margins were harder to work with. So, you think jolt is better to handle this? or we may end up in a situation similar to what we had in bullet?

Edit: I'm not sure my like to mihe is enough to assert my deep appreciation for his work so this line is juts to verbalize that in order to compensate what is in my eyes a message that could be misinterpreted as a devaluation of it.

[adamscott]

If this is recommended as an official addon and seem like, in the long term, it could provide more advanced tech that godot physics, would that not imply a decrease activity on the development of the Godot physics engine?

If the add-on is successful enough and if there's a conversion of the add-on into a native Godot module, yes, it would mean a decreased activity on the development of the 3D Godot physics engine, especially if there's no maintainer that is able to maintain/upgrade our current engine.

If that is the case, as is my understanding that people deep in physics are only a few, how could this impact on the development of the integrated physics?

The development of the physics engine is already impacted. See the tweet of Juan in the proposal.

If the people who is currently working on godot physics eventually find that jolt is in fact a better option, and that leads to provide Godot with a limited or unmaintained physics engine, does it not make more sense to put this into the engine by default like Bullet was?

Yes, it makes a lot of sense. But as the Jolt Physics engine is not yet at feature parity with the 3D Godot Physics engine, we (the production team) think that there's no rush to replace the Godot Physics engine yet. Especially as the add-on works very well as a GDExtension. Once Jolt Physics, Godot Jolt and GDExtension will be battle tested, we'll think about merging the projects together. Until then, no.

I remember when we were talking about the Godot physics issues that two points were often pointed out: That using a library was easier to implement basic functions, but that it requires a bigger understanding to debug issues while implementing more advances features. This was notorious in move and slide. The other was that physics engines with margins were harder to work with. So, you think jolt is better to handle this? or we may end up in a situation similar to what we had in bullet?

We think that we'll know more about this if more and more users start to use Godot Jolt as their main physics engine. And as Jolt was made from the ground up to be a video game physics engine, we think that it will be more stable than Bullet, as it wasn't made with video games in mind.

[yosoyfreeman]

Thank you so much for taking the time to explaining this topic. I honestly feel like any possible concern is covered and seems like a good roadmap. As usually, awesome work from the team. Thank you all!

[golddotasksquestions]

Godot Physics is a disgrace of a bugfest. The only chance to get it halve-decently working is to limit your collision shapes to simple box and sphere primitives (not always a feasible option). In stark contrast to the much more performant Godot Jolt. Even with non-feature parity Godot Jolt is a much more viable physics engine. I really hope the combined efforts are focused on Godot Jolt going forward.

Previous discussion on this topic: #5161

[yosoyfreeman]

well, I'm going to break a spear in favor of the Godot Physics engine. Yeah, it has serious troubles. But i just can't believe that a whole replacement for bullet was created in order to address the core functions for Godot 4.0 SO quickly. Not only Godot physics itself, but the work put into interface, a better API, more control of the bodies from the inspector, the whole new CharacterBody, which i think that while still could be improved (Like all things can) is an exponentially better solution for characters that what we had before. A huge effort went into testing and creating controllers in lots of ways to achieve something general enough for Godot while providing high level functionalities like snapping, constant velocity on slopes etc.

The physics engine is a thing, the implementation of it is another one and i think the team made huge steps on the right direction there. And just to be fair, the users who actually spend time creating reproduction projects for issues that were really hard to identify by the team was not so big.

Not so long ago just checking if a character was on the floor reported serious troubles and we are now far away from that. I don't think is fair to call the work a disgrace.

[jrouwe]

Hello,

I'm flattered that Jolt Physics is being considered for integration in godot. It has a been a lot of fun to develop it together with @mihe and I think it is amazing to see how quickly he implemented all of this!

The other was that physics engines with margins were harder to work with. So, you think jolt is better to handle this? or we may end up in a situation similar to what we had in bullet?

@yosoyfreeman I've heard multiple people say bad things about collision margins so far, but I have never experienced any issues with them. What is so bad about them?

B.t.w. I think the margins probably work differently in Jolt than in other physics engines. If you specify a margin, it gets subtracted from the shape and then re-added again, creating a shape with rounded corners of the same size as the original shape. The margins are only used to during the initial overlap test as a performance optimization, but not when calculating contact points/normals, these use the original shape. For ray casts they're not used at all. The only downside is that you may miss a hit if the overlap between two shapes falls between the original edge and the rounded off edge. I've not seen any artifacts due to this, but if this is important to you you can easily set the margin to 0 and pay some extra CPU cycles during the collision detection phase. For meshes / heightfields the margin is always zero, so I think this really only matters for boxes, convex hulls and cyclinders.

[yosoyfreeman]

I apologize, i totally forgot about thanking you! I officially extend my congrats to you and anyone who worked in this, just to be covered! haha

@yosoyfreeman I've heard multiple people say bad things about collision margins so far, but I have never experienced any issues with them. What is so bad about them?

i don't know from the programming side, but user side they seem a bit confusing to work with, but i see that they way they are handled is not equivalent to how bullet did it, so I'm not worried about them anymore. I started to try jolt and i was expecting something way more complicated bullet style. I'm honestly surprised in the best sense possible. You really did a great job here.

[mihe]

I've been curious about the differences between Bullet and Jolt with regards to margins, since this gets brought up in every discussion about the viability of Jolt and other GJK/EPA-based physics engines, so here are a few quick observations...

I think the margins probably work differently in Jolt than in other physics engines. If you specify a margin, it gets subtracted from the shape and then re-added again, creating a shape with rounded corners of the same size as the original shape.

From what I can tell, the margins as used with Bullet in Godot 3 behave similar to Jolt when dealing with boxes and cylinders, where you'll get rounded edges but no extra margin/padding/skin around it. With convex hulls you do however (unlike Jolt) get this extra margin/padding/skin around it, which when skimming through Godot's list of issues here on GitHub seems to have been the source of some confusion/frustration (godotengine/godot#27427, godotengine/godot#55503).

The margins are only used to during the initial overlap test as a performance optimization, but not when calculating contact points/normals, these use the original shape.

This is actually confusing me a little bit, as this does not reflect what I've seen in Godot Jolt, but in the interest of not derailing this discussion too much I'll create a separate issue for this, since I might have misunderstood or screwed something up in my implementation.

In either case, from what I can tell with just some quick tests, Bullet in Godot 3 seems to again be inconsistent about this depending on the shape type, where contact normals for boxes don't seem affected by shape margins but convex hulls do.

For ray casts they're not used at all.

Without trying this in Godot 3 myself, this seems to be another discrepancy with Bullet, where margins do seem to affect ray-casts and seem to again have been the source of some confusion/frustration (godotengine/godot#28032).

if this is important to you you can easily set the margin to 0 and pay some extra CPU cycles during the collision detection phase

This was not the case with Bullet in Godot 3, which I think is where a lot of the apprehension comes from. The margin had to be a non-zero value, so you could never really opt out of this performance-for-accuracy trade-off.

In Godot Jolt I've also added a project setting to globally ignore the shape margins, if you don't feel like setting it to 0 for every single box/cylinder/hull.

I think this really only matters for boxes, convex hulls and cylinders.

This was the case with Bullet in Godot 3 as well, but for whatever reason the margin parameter is present on all shape types, but ignored for anything but boxes, cylinders and convex hulls.

[mihe]

Here are the discrepancies/compromises that I meant to bring up in my original reply. Apologies in advance for the wall of text.

These things are (hopefully) not blockers per se, for the purpose of recognizing Godot Jolt as an official add-on, but seeing as how this proposal is largely intended to be an intermediate step towards making Jolt a first-class physics implementation in Godot I do think it's important to keep these in mind.

Note that this likely isn't an exhaustive list, and I've probably left out something important, but it'll have to do for now.

TL;DR

• Any custom nodes exposed by Godot Jolt can't be used from compiled languages.
• Joints mostly work, but advanced features will require use of custom nodes.
• Level of compatibility with SoftBody3D is yet to be determined.
• WorldBoundaryShape3D is not supported and likely never will be.
• HeightMapShape3D is more restrictive than its Godot Physics counterpart.
• Level of compatibility with double-precision is yet to be determined.
• Performance is mostly very good indeed, but comes with a few pitfalls.
• Shape margins are a thing, but don't behave as in Bullet, and can be disabled.
• iOS/Android is not supported yet, but will be.
• Web is not supported.
• Thread-safety is not a thing yet, but will be.

Bindings (C#, C++, Rust, etc.)

I think this is an important point to keep in mind as I go through the rest of this list, which is that you currently cannot interact with custom nodes that are exposed through GDExtension from languages that require compiled bindings, such as C#, C++, Rust and others. This means that when there's a mismatch between the interface that Godot expects you to implement (through PhysicsServer3DExtension) and the interface that Jolt provides there isn't much available in terms of options other than to drop support for that feature for these compiled languages, since you're not able to patch those holes with new nodes.

My current (perhaps naive) plan for the custom joints (described below) is to work around this for C# by distributing a separate NuGet package containing some sort of handwritten bindings that utilizes things like Object.get, Object.set and Object.call, but even so it will likely be a point of friction both in terms of development and usage.

GDScript and (presumably) other dynamic scripting languages are unaffected by this limitation.

Joints

Godot Jolt supports the basic functionality of all the default joint nodes, meaning they're all constrainted on the expected axes and they all support whatever hard limits and motors that the joints offer.

The only exception is perhaps SliderJoint3D, which in Godot Physics (and Bullet) also supports rotating/motoring around the sliding axis. In Jolt this is instead (rightfully) left up to the 6DOF joint. It's of course entirely possible to just implement SliderJoint3D using Jolt's SixDOFConstraint instead, perhaps even dynamically based on the properties used, but I haven't felt the need to take on that complexity yet.

What's also not supported in all these default joint nodes (and likely never will be) are the parameters that tune how the joints behave as the bodies move around or when they run up against the joint's limits. This includes things like bias, damping, relaxation, softness, restitution and ERP. Attempts were made to try and translate these into the interface that Jolt expects, but due to the lack of a consistent/functioning reference implementation this was eventually abandoned.

The current plan is to instead expose Jolt-specific joint nodes, appropriately named JoltPinJoint3D, JoltHingeJoint3D, etc. These will look and behave much like the default joint nodes, but will instead use Jolt's frequency/damping to express things like springs and soft limits. This also opens up for things like breakable joints, since Jolt allows you to retrieve a joint's last applied impulse. You will also be able to override the number of solver iterations on a per-joint basis, allowing you to make certain important joints more stable.

SoftBody3D

As already pointed out earlier in this thread, this isn't currently a thing in Jolt, but seems to be in the pipeline.

It remains to be seen how the two interfaces will line up. SoftBody3D in Godot Physics seems to be based on the PBD implementation in Bullet, and seeing as how the pending implementation in Jolt is based on XPBD I'm thinking/hoping they might be similar enough for the Godot Jolt implementation to be functional at least, without having to go down the route of making a custom node.

WorldBoundaryShape3D

This shape represents a static infinite plane in Godot Physics, and judging by the name is meant to be used for expressing world boundaries.

This type of shape is explicitly not supported in Jolt due to the implications its infinite nature has on performance and floating-point accuracy. I made a naive attempt at implementing this (before seeing the linked issue) by triangulating the plane, similar to Bullet's btStaticPlaneShape, and I can attest to quickly running into those floating-point issues.

Seeing as how this shape doesn't really offer much that can't be achieved with other shapes or mechanisms, I don't personally have any issue with this being unsupported, but it's none the less a discrepancy to consider.

HeightMapShape3D

While this shape is supported and mostly functional in Godot Jolt, it does come with the restriction that you can only use square height maps with dimensions that are a power-of-two. So you're only allowed to use height maps like 1024x1024 and not 1024x512 or 1000x1000.

Double-precision

This is something I haven't had the chance to explore yet, and while Jolt does support double-precision, it does so in a more conservative manner than Godot's approach of making most things a double. As such, there might be some slight discrepancies here with regards to the precision by which you're able to perform certain operations. I doubt it'll be of any practical concern, but it's still somewhat unknown at the moment, for me at least.

Performance

While Godot Jolt does seem to perform better than Godot Physics in most cases, there are certain cases where it does not.

One such case is when you manipulate the shapes of a body (i.e. change their properties/transform) after it has entered a scene tree. This is due to the fact that I lazily build the (fairly expensive) underlying Jolt shapes only when necessary, so as long as the body is not inside a tree you can manipulate the shapes whichever way you want at virtually no cost, but once the body is inside a tree then I rebuild the shapes immediately on every single change.

This is prominently noticeable in the Voxel Game demo project, where the chunk streaming results in pretty severe stuttering as you move around due to the chunks being initialized with dummy shapes that later gets replaced with proper ones, leading to multiple expensive rebuilds of the body's StaticCompoundShape. In this particular case it can be resolved fairly easily with a few minor tweaks, but it's a non-obvious pitfall either way.

These pitfalls are not inherent to Jolt, and more of a conscious trade-off that I made to prioritize the performance of bodies that do not change their shapes very often. You could of course do all sorts of dirty-flagging to only rebuild once per tick, or use some sort of heuristic or project setting for deciding whether a MutableCompoundShape is more appropriate than the StaticCompoundShape I use currently, but this comes at the cost of complexity, which I just haven't felt the need for yet.

Another performance pitfall relates to how Area3D detects StaticBody3D, where you can end up shooting yourself in the foot from a performance/memory standpoint if you allow many/large Area3D to overlap with complex static geometry, such as ConcavePolygonShape3D or HeightMapShape3D, due to how Jolt implements its Sensor body. For this reason this feature is gated behind a project setting in Godot Jolt.

There might very well be more performance pitfalls/discrepancies that I'm not aware of, as well as low-hanging fruit in terms of performance gains, but I haven't had much time to focus on profiling/benchmarking yet.

Miscellaneous

There are some other discrepancies that I'll just quickly list off here:

• Shape margins - See the previous replies in this thread. They don't behave like in Bullet and can be easily disabled.
• iOS/Android support - This should be fairly straight-forward, but I haven't gotten to it yet.
• Web support - I have no plans to support this currently, see this issue for more details.
• Thread-safety - I haven't made up my mind on how to approach this yet, but I'll probably go the same route as Godot Physics by implementing something similar to its PhysicsServer3DWrapMT.

[dsnopek]

I think this is an important point to keep in mind as I go through the rest of this list, which is that you currently cannot interact with custom nodes that are exposed through GDExtension from languages that require compiled bindings, such as C#, C++, Rust and others.

I think this is might be solvable, at least with GDExtension (I'm not sure about C#).

When you have the Jolt GDExtension enabled, you could run godot --dump-extension-api and use the resulting extension_api.json when building your own C++ or Rust (or whatever) GDExtension, and it would generate the necessary code to use the custom Node types from Jolt.

Unfortunately, thinking through this I suspect a recent-ish change that I made for Godot 4.1 may actually prevent this from working at the moment :-) but I haven't tested it. Anyway, if it does, that's just a bug that can be fixed!

[mihe]

When you have the Jolt GDExtension enabled, you could run godot --dump-extension-api and use the resulting extension_api.json when building your own C++ or Rust (or whatever) GDExtension, and it would generate the necessary code to use the custom Node types from Jolt.

That could be interesting. I guess one could then technically maintain a fork of godot-cpp (or whatever) that includes that modified extension_api.json. Obviously this wouldn't compound very well if multiple extensions start to take this approach, but it's something to consider.

I'm not sure about C#

I've seen mentions about something similar having been used for C# in the past, where you'd have the desired extensions loaded while generating the C# glue or something along those lines. I'm not sure how that would have worked exactly, but either way that is now also likely broken (by me) since godotengine/godot#75955, which causes the C# scripting to explicitly skip over GDExtension classes when instantiating its bindings.

[reduz]

My thinking here is that, eventually, we can break some compatibility on the Godot side to make this happen, given most of these features are probably not heavily used, but some things will have to be properly supported. Here are my feelings about this:

This is the list of things that can be adapted in Godot to work like Jolt, even at the cost of breaking compatibility:

• Joints and motors: The way Jolt exposes joints makes more sense than the one Godot does. It is also far more robust. For this, extra enums in the PhysicsServer3D joints need to be added to add the Jolt parameters. Each physics engine will support its own. Likewise on the nodes, the new parameters need to be added and a small trick can be done to hide one or another parameter depending on the physics engine active. Eventually, when GodotPhysics is removed, we deprecate the old parameters and remove them.
• Compound Shapes: I don't understand this well, but it looks like Jolt has both mutable and static compound shapes? Godot users will modify anything they can dynamically because such is the nature of a general purpose game engine. This needs to be supported as well as possible. If an optimization exists when they will be static, it can be something the physics engine is informed of in order to use a most efficient way. But here, again, you will have to assume users will change anything at anytime in every frame by default.
• HeightMapShape3D: This is something that should work in all cases also in Godot because there is too much code written already by ysers. One thing we could do here is, if the parameters to create the height map are not supported by Jolt, use a triangle geometry fallback and push a warning (once) that this will be less efficient, suggesting the most efficient size.
• Area3D against static bodies I think this can be dropped as it does not have a lot of sense as a feature. IMO it should test against kinematic bodies, but for static it is unnecesary.

This is the list of things that Godot can't adapt as well and we should figure out a better solution:

• WorldBoundaryShape3D: This is something Godot users use a lot. Generally to define game play bounds, detect when things fall out of the world, etc. I think we should be able to figure out a way to do this. I can imagine it would be a pain to implement this in Jolt just for our use case, but also these are always used for static shapes. One option could be to just put a lot of boxes as a compound shape, though not ideal. The other would be if Jolt could let the user extend the collision / solver steps so these shapes could be implemented outside as a custom step. These need to be brute force tested against all dynamic shapes and generate a collision, or something like that. The collision code against a plane is super easy anyway.
• Threading: I am not exactly sure how Jolt uses threads, but Godot has its own scheduler (and soon its own profiler), so it would be ideal (if not the case already) if Jolt could allow overriding the functions used to send work to threads and await it by providing some custom function pointers. This way, the work Jolt does on threads would show up in the Godot profiler.
• Profiling Hooks: Again if not the case already, it would be great if Jolt would support profiling hooks (like broadphase, narrow phase, constraint solving, etc) so eventually it shows in Godot profiling properly.
• Memory Allocation: This is not a must, but it would also be great if Jolt would allow supplying custom functions to do memory allocation. Godot tracks all memory used in debug mode over time and right now it has tight control.
• iOS/Wasm/etc If Godot implements Jolt officially, we will just copy the entire Jolt codebase inside the Godot repository and do our own builds anyway, ensuring it works in all platforms. This is handled from our side, so it should be fine.

I think none of the above is serious, although probably the one that may need a more involved solution is WorldBoundaryShape3D. I think if Jolt can figure out a way to expose the right hooks to do it, even if its more work from our side, it should be fine.

[mihe]

Joints and motors: [...] For this, extra enums in the PhysicsServer3D joints need to be added to add the Jolt parameters. [...] Eventually, when GodotPhysics is removed, we deprecate the old parameters and remove them.

This sounds a lot like what I've already done with the custom joints I've added so far. The default and custom joints both share the same physics server implementation, and the custom ones just use a couple of extra enum values, which seems to be working well enough.

Compound Shapes: I don't understand this well, but it looks like Jolt has both mutable and static compound shapes? Godot users will modify anything they can dynamically because such is the nature of a general purpose game engine. [...]

I'm sure @jrouwe can be more specific here, but yes, Jolt's MutableCompoundShape is just a list of shapes that can be added/removed from whenever, and StaticCompoundShape is an immutable one that builds some sort of tree structure to speed things up.

Just to be clear, Godot Jolt supports adding/removing shapes whenever just fine, but in part to simplify the implementation I went with discarding and rebuilding the entire compound shape whenever this happens. I know I explored the (arguably more intuitive) option of just using a MutableCompoundShape that's simply kept around and mutated, but abandoned it for reasons I can't exactly remember right now. I'm sure it can be made to work somehow though.

HeightMapShape3D: [...] One thing we could do here is, if the parameters to create the height map are not supported by Jolt, use a triangle geometry fallback and push a warning (once) that this will be less efficient, suggesting the most efficient size.

@jrouwe also suggested this in godot-jolt/godot-jolt#502 yesterday, along with a few other things. This should be fairly straight-forward to resolve one way or another, if only just as a way to get to parity with Godot Physics.

Area3D against static bodies: I think this can be dropped as it does not have a lot of sense as a feature. IMO it should test against kinematic bodies, but for static it is unnecesary.

This was (to my surprise) some of the first issue reports that I got, multiple even, which made it seem to me like it was a pretty popular use-case, although I can't speak to how exactly it was being used. I suppose if a user attaches an Area3D to something dynamic they expect every overlapping body to be reported, including static ones. It can obviously be replaced on the user's side by something like intersect_shape just as well, but that's not as convenient I suppose.

I realize Area3D is already kind of implemented this way in Godot Physics, but maybe some node equivalent to intersect_shape could be added, similar to how there's a RayCast3D and ShapeCast3D node, seeing as how there seems to be some friction with using PhysicsDirectSpaceState3D.

WorldBoundaryShape3D: [...] One option could be to just put a lot of boxes as a compound shape, though not ideal. [...]

I assume this wouldn't do much to alleviate the issue of the shape causing trouble for the broad phase, considering that the bounds of compound shapes encapsulates the bounds of all its sub-shapes, but I'm out of my depth here. I'm curious about your other suggestions though.

Threading: I am not exactly sure how Jolt uses threads, but Godot has its own scheduler (and soon its own profiler), so it would be ideal (if not the case already) if Jolt could allow overriding the functions used to send work to threads and await it by providing some custom function pointers.

If by scheduler you're referring to WorkerThreadPool, then this is already hooked up in Godot Jolt.

Profiling Hooks: Again if not the case already, it would be great if Jolt would support profiling hooks (like broadphase, narrow phase, constraint solving, etc) so eventually it shows in Godot profiling properly.

From what I understand this is a thing through JPH_EXTERNAL_PROFILE, but I haven't looked at it even a little bit, so maybe @jrouwe can provide some more details here.

Memory Allocation: This is not a must, but it would also be great if Jolt would allow supplying custom functions to do memory allocation. Godot tracks all memory used in debug mode over time and right now it has tight control.

This is already a thing in Jolt, but due to Jolt also needing aligned allocations I wasn't able to use alloc_static/free_static exposed through godot-cpp, so I allocate memory through other means currently, thereby (unfortunately) bypassing Godot and its performance monitors. I assume this would be less of a problem if Jolt were brought in as a module though.

iOS/Wasm/etc: If Godot implements Jolt officially, we will just copy the entire Jolt codebase inside the Godot repository and do our own builds anyway, ensuring it works in all platforms. This is handled from our side, so it should be fine.

Yes. :)

[jitspoe]

B.t.w. I think the margins probably work differently in Jolt than in other physics engines. If you specify a margin, it gets subtracted from the shape and then re-added again, creating a shape with rounded corners of the same size as the original shape. The margins are only used to during the initial overlap test as a performance optimization, but not when calculating contact points/normals, these use the original shape. For ray casts they're not used at all. The only downside is that you may miss a hit if the overlap between two shapes falls between the original edge and the rounded off edge. I've not seen any artifacts due to this, but if this is important to you you can easily set the margin to 0 and pay some extra CPU cycles during the collision detection phase. For meshes / heightfields the margin is always zero, so I think this really only matters for boxes, convex hulls and cyclinders.

Really? Seems like I was getting non-flat normals using a cylinder character collider against a triangle mesh (all flat 90 degree angles for testing stair stepping), sometimes causing my character to bounce in the air. Disabling the margins fixed it.

[reduz]

@mihe Oh, great to know that most of this is taken care then!

Just some extra notes from what you answered then:

Just to be clear, Godot Jolt supports adding/removing shapes whenever just fine, but in part to simplify the implementation I went with discarding and rebuilding the entire compound shape whenever this happens.

Keep in mind also users often change the properties of the shapes (like making capsule shorter when character crouches)or animate them via AnimationPlayer. So I think my recommendation would be something like adding to PhysicsServer a flag to the body that specifies that you won't be doing changes often. As example, GridMap uses thousands of those and they are not changed, so it could optimize to have these static. Otherwise you may run into performance issues if users do too much of this.

This was (to my surprise) some of the first issue reports that I got, multiple even, which made it seem to me like it was a pretty popular use-case, although I can't speak to how exactly it was being used.

I am really surprised about this. It definitely should detect kinematic bodies (which are technically static) but I don't see the use of static collision either. I guess it makes sense to leave disabled by default.

WorldBoundaryShape3D

You really just need to skip the broadphase for it and just collide every non resting dynamic body forcibly against it. The collision is super simple, get the transformed shape support in the direction of -plane normal and check if under the plane. If so, it collides and you have to get the support features in that direction and use them against the plane and solve that. If a boundary shape is moved, wake up all bodies. Because this does not involve any broadphase and can be almost considered a constraint (except you have to query some supports at setup time), it should be relatively easy to implement "externally" or as a constraint if Jolt has the right hooks.

I also forgot to ask if you could handle the separator ray shapes. Users often use those to do stair stepping in characters (both dynamic and kinematic).

But this is really awesome anyway, it looks like you got pretty much all figured out !

[mihe]

I also forgot to ask if you could handle the separator ray shapes. Users often use those to do stair stepping in characters (both dynamic and kinematic).

Yes, these are implemented, and seem to work the same as in Godot Physics, at least when attached to kinematic bodies, including its slide_on_slope property.

I was under the impression that these were mostly intended for kinematic bodies, and while they technically work for dynamic bodies as well, I can't really give them a sensible mass/inertia, given their infinitely thin nature, so I currently just give it some arbitrary ones, which might differ from how they behave in Godot Physics. Although, I guess this shouldn't matter much for some RigidBody3D-based character, since they override mass anyway, and would likely use lock_rotation, which overrides the inertia as well.

[reduz]

@mihe They are used for dynamic character controllers too (mostly for stepping too), but its as you say it should be fine.

[elvisish]

Godot Physics is a disgrace of a bugfest. The only chance to get it halve-decently working is to limit your collision shapes to simple box and sphere primitives (not always a feasible option). In stark contrast to the much more performant Godot Jolt. Even with non-feature parity Godot Jolt is a much more viable physics engine. I really hope the combined efforts are focused on Godot Jolt going forward.

Previous discussion on this topic: #5161

Not sure why this has been downvoted so much, it's very true that you have to use Box colliders exclusively if you don't want the physics to level-reset break (which is the first rule of physics to avoid, never get stuck in a place you can't get out). I'll reiterate that using a Safe Margin of 0.001 instead of the default 0.0001 fixes getting stuck entirely in my experience, however I am still using only box colliders and simple 45 and 90 degree angled colliders so it may not work for more complicated shapes.

I absolutely agree that Jolt should be developed as the built-in default physics though.

[reduz]

@elvisish Godot Physics can be fixed with a good amount of effort (There was a roadmap more or less in place, and all issues are well understood) but the truth is that this still needs a dedicated maintainer and se far this has not happened. As Jolt has improved so much and became more friendly to how Godot works, plus it is very actively maintained and developed, at this point it makes more sense to move to it. This is why I think the change of plans makes more sense.

[elvisish]

@elvisish Godot Physics can be fixed with a good amount of effort (There was a roadmap more or less in place, and all issues are well understood) but the truth is that this still needs a dedicated maintainer and se far this has not happened. As Jolt has improved so much and became more friendly to how Godot works, plus it is very actively maintained and developed, at this point it makes more sense to move to it. This is why I think the change of plans makes more sense.

I agree. Just thinking now, I wonder if this means that stair-stepping could be implemented in Jolt physics for performance purposes? I've been using https://github.com/mrezai/GodotStairs for extremely robust and fully working stair-stepping (it does multi-directional shapecasts using directspace) but the performance is terrible (here's a stress test of 250):

Nvidia's PhysX has built-in stair-stepping as it's designed for games, I would expect Jolt to have similar built-in functionality and I think vastly improved performance would be an even better reason to have it built-in than convenience and the popularity of its use. Here's my 2+ year old proposal: #2751

[reduz]

@elvisish Just use a SeparationRayShape for stair stepping, this is what most users do. Also, we can move this discussion to your proposal, since you are going fully offtopic here.

[Griiimon]

What's the next step here?

This is currently a Top 10 ranked proposal, yet there has been no official update on this subject. Everyone here seems to be in agreement that it's time to officially endorse the plugin. I can't see any argument against it anymore.
I understand that we can't just replace the default Godot v4 physics engine. But this proposal doesn't even goes as far as suggesting that Godot-Jolt should be included in the core, much less replace the existing engine. It's simply about being finally recognized from the official side as an overall better option than the built-in 3D physics.

Godot-Jolt has become the recommended 3D physics engine in the community - over Godot Physics.
The level of maintance Godot-Jolt receives and even the support you will get is better than for Godot Physics. The original Jolt dev is actively implementing features to bring the engine to parity with Godot.

I think what should be done is:

• Mention the Godot-Jolt plugin in the official documentation as a viable/legit/recommended replacement for the built-in 3D physics. I realize that you want to avoid linking to unofficial 3rd party plugins in the offical docs but this is a case where the built-in module just isn't up to par and has no, hasn't had for while or doesn't seem to be getting a dedicated maintainer any time soon.
• Make an official statement about Godot-Jolt, it's widely spread use in the community already, the stale state of Godot Physics vs the continued efforts put into the plugin and the possibility of it being included in core in the future.

I believe that would count as "officially endorsing" the plugin and we can finally close this proposal and move on to the next stage in the process, which is the one most of us are actually concerned about: making it a core feature.

[Mantissa-23]

I think what should be done is:

• Mention the Godot-Jolt plugin in the official documentation as a viable/legit/recommended replacement for the built-in 3D physics. I realize that you want to avoid linking to unofficial 3rd party plugins in the offical docs but this is a case where the built-in module just isn't up to par and has no, hasn't had for while or doesn't seem to be getting a dedicated maintainer any time soon.

• Make an official statement about Godot-Jolt, it's widely spread use in the community already, the stale state of Godot Physics vs the continued efforts put into the plugin and the possibility of it being included in core in the future.

I believe that would count as "officially endorsing" the plugin and we can finally close this proposal and move on to the next stage in the process, which is the one most of us are actually concerned about: making it a core feature.

So, I'd like to add a third item here, I did mention it in my comment above yours but I don't want it to get lost-

godot-jolt/godot-jolt#356 (comment)

If you check this thread in godot-jolt, the author is hoping for godot-jolt to get merged in as an official module. As in, not just endorsed by Godot's developers, but something that comes with Godot 4 by default, that you can switch to in the settings without having to install anything, or perhaps even becomes default for new projects, overshadowing Godot's built-in physics. This is very different from a simple documentation change/announcement, and I would guess it's why we haven't seen any comments from the major contributors.

It's a pretty big piece of work, and a decently large shift in Godot's attitudes towards use of external libraries (that is- There seems to be a general avoidance of large external libraries for big pieces of engine functionality. Small libraries have been used, but generally the Godot team seems to prefer to do things in-house, with some obvious exceptions like Vulkan/OpenGL where rolling your own isn't a practical option).

This would provide benefits that @mihe explains a lot better than I can, but the tl;dr is that it would enable thread safety, providing both performance improvements as well as pulling godot-jolt off of the main thread. I imagine there would be other benefits to turning this into a module as opposed to a gdextension that I am not aware of.

Edit: Just saw that you intended these as a stepping stone to godot-jolt being a core feature, my bad. Regardless- I feel like we're at the point where the main benefits would be in just merging it in as a module. But I think that would be a conversation godot's devs have to have directly with jolt's.

[rossbridger]

I think what should be done is:

• Mention the Godot-Jolt plugin in the official documentation as a viable/legit/recommended replacement for the built-in 3D physics. I realize that you want to avoid linking to unofficial 3rd party plugins in the offical docs but this is a case where the built-in module just isn't up to par and has no, hasn't had for while or doesn't seem to be getting a dedicated maintainer any time soon.
• Make an official statement about Godot-Jolt, it's widely spread use in the community already, the stale state of Godot Physics vs the continued efforts put into the plugin and the possibility of it being included in core in the future.

I believe that would count as "officially endorsing" the plugin and we can finally close this proposal and move on to the next stage in the process, which is the one most of us are actually concerned about: making it a core feature.

So, I'd like to add a third item here, I did mention it in my comment above yours but I don't want it to get lost-

godot-jolt/godot-jolt#356 (comment)

If you check this thread in godot-jolt, the author is hoping for godot-jolt to get merged in as an official module. As in, not just endorsed by Godot's developers, but something that comes with Godot 4 by default, that you can switch to in the settings without having to install anything, or perhaps even becomes default for new projects, overshadowing Godot's built-in physics. This is very different from a simple documentation change/announcement, and I would guess it's why we haven't seen any comments from the major contributors.

It's a pretty big piece of work, and a decently large shift in Godot's attitudes towards use of external libraries (that is- There seems to be a general avoidance of large external libraries for big pieces of engine functionality. Small libraries have been used, but generally the Godot team seems to prefer to do things in-house, with some obvious exceptions like Vulkan/OpenGL where rolling your own isn't a practical option).

This would provide benefits that @mihe explains a lot better than I can, but the tl;dr is that it would enable thread safety, providing both performance improvements as well as pulling godot-jolt off of the main thread. I imagine there would be other benefits to turning this into a module as opposed to a gdextension that I am not aware of.

Edit: Just saw that you intended these as a stepping stone to godot-jolt being a core feature, my bad. Regardless- I feel like we're at the point where the main benefits would be in just merging it in as a module. But I think that would be a conversation godot's devs have to have directly with jolt's.

Last time I checked, Godot is a monolithic executable, and you can't just shove functionalities not everyone need into the Godot binary and make it bloated. Why would Godot need a native physics engine and a jolt engine inside it when many of the game developers only need it for 2D games? If Godot should take O3DE approach and allow its own modules be compiled as DLLs that can be included/excluded during packaging. That way maybe more optional modules can be trickled into Godot's code base.

[elvisish]

Last time I checked, Godot is a monolithic executable, and you can't just shove functionalities not everyone need into the Godot binary and make it bloated. Why would Godot need a native physics engine and a jolt engine when many of the game developers only need it for 2D games?

I would suggest reading every post in this very issue and the hundreds of other complaints about the current state of GodotPhysics to find an answer to that.

[NuclearPhoenixx]

Last time I checked, Godot is a monolithic executable, and you can't just shove functionalities not everyone need into the Godot binary and make it bloated. Why would Godot need a native physics engine and a jolt engine when many of the game developers only need it for 2D games?

For this exact reasoning we should get rid of Bullet as well and roll entirely with GodotPhysics?

[Griiimon]

So, I'd like to add a third item here, I did mention it in my comment above yours but I don't want it to get lost

This is what I was trying to avoid, actually. This proposal is about officially endorsing.
Your item needs to be a separate proposal down the line. Because if we combine these things it's way harder to get approval.
You can see that it immediate starts an argument and not everyone is in lockstep anymore. This thread should only represent the consensus about making the plugin official. So if anyone who is in an official Godot capacity -whatever that means - scrolls through thinks to themselves "that's what we all want and there's no reason to deny it anymore".

I mean that this proposal is still open should be prove enough that even baby steps seem to be too big right now.

[Griiimon]

I think what we should discuss is where in the documentation to add the link to Godot-Jolts repo or AssetLib entry.

I would like it on this page, for example
Troubleshooting physics issues
And kinda prominently featured at the top. But I'm not sure about the wording. Every time I start to write a sentence in my PR it sounds to critical of the built-in physics engine and I'm afraid it will get rejected right away because of it.

It needs to be a diplomatic way of pointing out that 3d physics in Godot 4 is in a borderline unacceptable state with no improvement in sight and the plugin fixes that.

[rossbridger]

Last time I checked, Godot is a monolithic executable, and you can't just shove functionalities not everyone need into the Godot binary and make it bloated. Why would Godot need a native physics engine and a jolt engine when many of the game developers only need it for 2D games?

I would suggest reading every post in this very issue and the hundreds of other complaints about the current state of GodotPhysics to find an answer to that.

I was replying to the idea of putting both godotphysics and jolt inside Godot as built-in modules. And I think if Godot wants to switch to an external physics engine, it should go with physX which is superior.

[jams3223]

Last time I checked, Godot is a monolithic executable, and you can't just shove functionalities not everyone need into the Godot binary and make it bloated. Why would Godot need a native physics engine and a jolt engine when many of the game developers only need it for 2D games?

I would suggest reading every post in this very issue and the hundreds of other complaints about the current state of GodotPhysics to find an answer to that.

I was replying to the idea of putting both godotphysics and jolt inside Godot as built-in modules. And I think if Godot wants to switch to an external physics engine, it should go with physX which is superior.

You would be limited to an older version of PhysX, which is barely supported, while the newer version remains closed source. Jolt also has better performance with a multithreaded CPU.

[reduz]

Given this thread is drowning in speculation, I want to give my take on what will probably be the next steps regarding to this:

• Jolt needs to be converted to a module and made eventually the default physics engine in Godot. I think everyone agrees on this.
• Unfortunately, as things stand, Jolt does not fully support everything Godot physics supports, so this can't happen as-is. Work needs to be done in order to get this to happen, and for this contributors need to either volunteer to do it, or funding must be allocated for this work. The differences must be assessed and an action plan needs to be laid out.
• Once this has been done, then Jolt can be integrated as a module.
• It can't be made default until it is certain it maps 1:1 with GodotPhysics and existing games do not break.
• Afterwards, extra functionality that Jolt offers can be also offered to Godot users.

When and how this will happen is uncertain (remember Godot is FOSS and it depends on contributor willingness and availability), but at least that is the plan.

But this will take time.

[Griiimon]

• Jolt needs to be converted to a module and made eventually the default physics engine in Godot. I think everyone agrees on this.

This sounds like recognition and official endorsement to me. I vote to close this Proposal as completed, there's really nothing more to add in my opinion.

Maybe it's time for a follow up tweet tho ;)
( Referring to this Juan Linietsky tweeting about the Jolt plugin )

A lot has been done since, Softbodies have been implemented and there are only a few very minor features missing. I'd say the plugin was at something like 75% feature parity back then and is at >95% currently.

• Unfortunately, as things stand, Jolt does not fully support everything Godot physics supports, so this can't happen as-is. Work needs to be done in order to get this to happen, and for this contributors need to either volunteer to do it, or funding must be allocated for this work. The differences must be assessed and an action plan needs to be laid out.

Just curious, is there anything left us normal folk can do about this? Like opening a new Proposal requesting to allocate funds towards this or leave an upvote somewhere?
I'm assuming these aren't options and the only thing we can do right now is wait or contribute to the plugin to achieve 100% feature parity, but I thought I'd ask at least.

[reduz]

@Griiimon there will be a public roadmap published soon after Godot 4.3 is out which will include a lot of this info regarding where the project expects to go.

This also should hopefully get a better idea of where funding is intended to be used.

[jrouwe]

Unfortunately, as things stand, Jolt does not fully support everything Godot physics supports

@reduz Is there anything in particular you're thinking about? If I look at What Is Not Supported then I think the biggest thing is thread safety, but as far as I understand that comes practically for free when it gets merged into godot. Other than that I'm happy to help.

[mihe]

@jrouwe WorldBoundaryShape3D (aka infinite plane shape) has come up during discussions about this. I've been meaning to take another look at what could be done about this (short of hacking it in with a bunch of boxes) but haven't really found the time. As touched upon earlier in this thread there are obviously some inherent problems with adding this type of shape, but backwards compatibility (within reason obviously) remains a sticking point, so something ideally needs to be done about it.

Maybe we can open another discussion about this, if you're open to it, even if it's just about allowing certain bodies to bypass the broad phase entirely and be brute-force checked against every other body, or something along those lines.

@reduz floated the idea of it maybe (under the hood) being a constraint of some type instead, but having (only briefly) looked at it I'm not sure that would work in Jolt, seeing as how you'd presumably have every body in the simulation (or at least the applicable layers) partake in that particular constraint island, but maybe you see some way of doing it. I could have misunderstood the idea as well.

[jams3223]

Unfortunately, as things stand, Jolt does not fully support everything Godot physics supports

@reduz Is there anything in particular you're thinking about? If I look at What Is Not Supported then I think the biggest thing is thread safety, but as far as I understand that comes practically for free when it gets merged into godot. Other than that I'm happy to help.

Man I love this guy, somebody give him legend status. I am glad you're helping get everything in a good shape.

[bughandler]

Good to know there is a plan.
But the only question to me is why Jolt needs to be a 1:1 replacement for the default physics engine to keep the backward compatibility? from 4.0 to 4.3 the engine has broken the backward compatibility several times in rendering, and animation areas, why does it come differently in physics?

[jrouwe]

Maybe we can open another discussion about this

Yes, let's continue here: godot-jolt/godot-jolt#104

[jrouwe]

The WorldBoundaryShape3D is implemented now and raycasts support returning face_index (pending a PR in godot-jolt).

@reduz @mihe Are there any more things that need to be fixed? I see 'SoftBody3D does not support any interactions with Area3D' on the list but I don't know how important that is. I can work on that next if needed (have looked at it before but it is difficult to get a performant implementation for it).

[mihe]

@jrouwe I can't speak for the Godot production team, nor have I been involved in all the discussions about this, so I'll leave it to them to give any sort of thumbs up, but I guess I can take the opportunity to bring up this discrepancy with Godot Physics:

Ray-casts using hit_back_faces will hit the back/inside of all shapes, not only concave ones

In short, Godot Physics only considers ConcavePolygonShape3D and HeightMapShape3D to have back-faces, and with any of the convex shapes it'll just go right through when done from inside of it, unless of course you also enable hit_from_inside, but that maps to Jolt's mTreatConvexAsSolid. Jolt on the other hand considers every convex shape (BoxShape3D, SphereShape3D, CapsuleShape3D, etc.) to also have a back-face (i.e. the inside of its hull).

This seems to be a fairly common¹ (albeit easily resolved) stumbling block when people migrate to Godot Jolt, as this hit_back_faces is enabled by default in Godot. A common use-case is people calling intersect_ray from within their convex Character3D shape and forgetting to add the Character3D to the exclude parameter of intersect_ray, because they didn't really need to with Godot Physics, and finding that they're hitting the inside of it all of a sudden, if they even spot the issue in the first place.

This can also manifest itself with the RayCast3D node, even though it automatically adds the above mentioned exclusion, if you (for example) put another node inbetween the Character3D and the RayCast3D, so that the Character3D is its grand-parent instead, which makes it so the exclusion is never added properly.

The fix for both of these cases is of course to just set hit_back_faces to false, or add the above mentioned exclusion, which is easy enough, but you have to also realize that this is what's happening, which is not obvious.

I have somewhat deliberately looked the other way with this particular discrepancy, waiting to hear if someone would scream loud enough for me to address it in some way (likely by making a request to you about it) because I felt that Jolt's behavior made more sense. I figured if/when Jolt becomes an official module then other breaking changes probably need to happen anyway (its behavior will never truly be 1:1 with Godot Physics after all) so changing the default value of hit_back_faces to false would just be one of them, which to me seems like a more sensible default.

This was brought up in one of the discussions surrounding all this, and I got the impression that making this breaking change wasn't that big of a deal in the greater context, so maybe it really isn't, and we should just leave it as-is, but if we're aiming to max out the 1:1 mapping with Godot Physics, and instead leave the breaking change for a later date, then this would be some low-hanging fruit I guess.

It could perhaps be that it's entirely fixable from my side using filters or something.

Footnotes

1. I have seen about a dozen or so mentions of this since I first released the extension. ↩

[jrouwe]

Spinning off another discussion here: godot-jolt/godot-jolt#957