Add (or at least investigate) Jolt physics engine

[jitspoe]

Describe the project you are working on

3D Retro FPS.

Describe the problem or limitation you are having in your project

I know Bullet had a number of issues, but the Godot physics engine has a lot of shortcomings as it currently stands and may require significant engineering efforts before it becomes viable for 3D games. Issues range from game breaking problems like getting stuck in/teleporting through geometry to rigid bodies just looking weird/not behaving physically accurately.

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

Ideally a physics engine developed for a AAA game (Horizon Forbidden West) will be a bit more robust and battle tested. I haven't actually looked into it in depth, but it sounds like it has more precision and deterministic behavior than Bullet, so it might be worth looking into.

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

This would be an optional physics engine alternative users could select from, like with Bullet was in 3.x.

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

No, this is core functionality.

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

It might be possible to make it an add-on. Not 100% sure how 4.x handles physics libraries. I do think it might be useful as a core feature, though, for people running into issues with the Godot physics engine.

Might, at the very least, be worth looking into for reference.

[Calinou]

Moved to discussion, as the proposal doesn't contain a concrete technical implementation.

---

Jolt can be integrated as a third-party extension, but it won't be tackled in core. The reason is the same as Bullet: we don't want to rely on third parties to maintain a physics engine. If we do this, we are reliant on any decision they make (including stopping the maintenance of the engine, shifting the focus towards non-game use cases, etc).

Jolt is a physics engine that was designed for a single AAA engine, so it's easy for it to become unmaintained over time – probably even more so than Bullet. This is especially the case if its maintainers aren't interested in building a community, which is unfortunately quite common in libraries like this.

Jolt also currently lacks support for double precision physics, which is a must-have feature for Godot 4.x. While double precision physics aren't enabled by default, it's important that Godot can be built with it without losing any other functionality.
Edit: As of 2023, Jolt now supports double-precision physics.

There are still many things that will be fixed/improved in GodotPhysics before 4.0 is released, so I wouldn't use its current state to judge how it will behave in the stable release.

[jitspoe]

Oh, that's surprising. I figured it would. Doesn't Horizon have pretty large worlds? Anyway, yeah, having it as an extension is fine. I just wanted to get a discussion started as it might be worth looking into, if nothing else for reference.

[azur-wolve]

double precision physics aren't enabled by default

@Calinou Where can find such setting, only 4.x?

[Calinou]

Doesn't Horizon have pretty large worlds?

It does, but the game has loading screens between areas (or origin shifting, I don't remember). Therefore, it can manage having 32-bit physics just fine.

@Calinou Where can find such setting, only 4.x?

It's a compile-time SCons option (float=64). This cannot be provided as a run-time setting, as changing C++ core types can only be done at compile-time.

There are no plans to provide precompiled double-precision binaries for now, but nothing prevents a third party from doing so.
Edit: See #5610.

[azur-wolve]

@Calinou thx
IIRC heard that Godot 4.x will have float64 coordinates for Vectors (similar to the shifting Unreal has done recently)

[golddotasksquestions]

I did not know Guerrilla physics engine was open source. I find this very interesting.
I mean look at those: https://www.youtube.com/channel/UCT5ZTPeBOKnlPgwjHAPlFLA/videos

I understand why the Godot physics team does not want to be dependent on some external library maintainers, but I would love to know what speaks against forking Jolt and using it as starting point for Godot's own physics system.

I mean Jolt already has way more features (lovely constraints, animated ragdolls!) than we might even have in years to come, but much more importantly: Jolt went through AAA QA and a world famous release. It went through hundred thousands of play testers.

Even when Godot Physics finally is able to replace Bullet, how long will it take to get it to a point where it has this feature set, and more importantly: when will it ever get this much testing?

[azur-wolve]

If fork another physics solution, have no guarantees that future updates to it wont break with Godot's bridge implementation.
But could be done as a plug-in with a wrapper, like Rapier, if someone is disposed to do it and maintain it.
Bullet also will be bridged this way for Godot 4.x

[golddotasksquestions]

@KiwwiPity

If fork another physics solution, have no guarantees that future updates to it wont break with Godot's bridge implementation.

Well, of course! But this does not seem to be a valid argument in this case, since writing a completely new custom physics engine definitely does not allow future updates of another physics library either.

My question was why not use Jolt "as a headstart" for custom Godot physics engine, rather than trying years to come close to the feature set and especially the testing and real world application Jolt went through?

[azur-wolve]

@golddotasksquestions to get an answer you must go to the developers rocket chat (come back and tell us what you get if so)

[19PHOBOSS98]

I'm kind of thinking it over... the double precision thing looks supper important for Godot 4.0. I could work on adding Jolt as a third party extension for Godot 3.x but ultimately it wouldn't be added to Godot 4.0 or atleast anytime soon...

Jrouwe mentioned they would work on adding doubles eventually but it seems Jolt runs better on floats for now... I could lend a hand at adding doubles to Jolt to add it to Godot 4.0 but this will take time.

From what I saw most of Godot 4's inhouse physics engine is based off of Bullet already... Some features still need to be implemented like the joint constraints solver.

Work already started on the other parts of Godot's inhouse physics engine but Im not really sure if it's based on Bullet too...

The way I see it, Jolt needs a major revamp (mostly get double precision support) to base the inhouse engine off of it AT LEAST. Not to mention writing over a lot of what people already worked on...

At best we could have it as a third party library like Bullet for 3.x

And Linietsky did say we would be able to add other physics engines via GDExtensions in 4.0...

[elvisish]

There are still many things that will be fixed/improved in GodotPhysics before 4.0 is released, so I wouldn't use its current state to judge how it will behave in the stable release.

A physics engine needs to be perfect, that's essentially its purpose is to be 99.9% guaranteed not to break unless the most incredibly remote situations occur; Doom from 1993 has proven its robustness by just how ridiculous the situation the player must get in to cause any kind of game breaking issues (and even mostly these don't break the game, merely cause clipping errors).

At present, the player merely has to walk over or under geometry that is slightly unusually (ie: not a 90degree box) and you'll get stuck... and I don't mean glitch, I mean hard reset the level stuck, which is one of the golden rules of physics engines, never to get in a situation that is impossible to get out of.

I'm not criticising the work on GP, quite the contrary, I think it is incredible that such an undertaking was attempted as most physics engines are brought in from road-worn external sources that have complete focus on the development. But, I can't possibly imagine all the bugs that currently plague GP could be fixed before 4.0 RC (going on the current pace of development) and I would suggest an official implementation of a fully working physics engine so as there doesn't need to be only one broken solution available.

[Calinou]

Follow these simple rules and GP is perfectly usable!

The first two rules you mentioned are actually pretty common in games. All id Tech and Source engine games follow it for their player characters. They still rely on AABB collisions, not even using something like octagons.

[elvisish]

Follow these simple rules and GP is perfectly usable!

The first two rules you mentioned are actually pretty common in games. All id Tech and Source engine games follow it for their player characters. They still rely on AABB collisions, not even using something like octagons.

I actually prefer this method anyways as it's more vintage accurate and you don't have that weird sloping off edges like capsules give you. Was surprisingly hard to do it in Unity as PhysX only allows capsules.

[golddotasksquestions]

Follow these simple rules and GP is perfectly usable!

The first two rules you mentioned are actually pretty common in games. All id Tech and Source engine games follow it for their player characters. They still rely on AABB collisions, not even using something like octagons.

Common in retro games. Unless Godot Physics is branded as "retro physics only", this hardly is an argument.

[elim2g]

Follow these simple rules and GP is perfectly usable!

The first two rules you mentioned are actually pretty common in games. All id Tech and Source engine games follow it for their player characters. They still rely on AABB collisions, not even using something like octagons.

Sure, but it falls apart when you want to do something like walking up stairs - GP's shapecasting for small distances is very poor. With the same set of inputs you can simply fail a test and step up a wall despite having already collided with it because moving the shape up and then forwards a small amount now "suddenly" doesn't collide. "Okay, probably because the shape is now partially inside of the geometry" you think, and so you attempt to move it away slightly before performing the same action. You spar with the tolerances until you find something that seems to work, only to knock into an edge case again later. You simply don't experience this in well-worn physics engines. Sure - they all run into issues with tolerances (unavoidable with flops) however I've never seen it require this much effort from the gameplay side before.

TL;DR: Even if I want to treat GP as an AABB simulator from 96, it still fails basic tasks.

[timshannon]

@elim2g Is there an open issue for that? I think I may be running into the same issue.

[Ansraer]

For the record, Jolt does now support double physics (and does it with loosing barely any performance compared to float).

[mihe]

I was messing around with adding a Jolt-based physics server to Godot as an engine module a few months back, with the intention of moving it to a GDExtension once that API was more fleshed out.

Once godotengine/godot#65427 was merged I started working on getting it running on the major desktop platforms (Windows, Linux, macOS) as a GDExtension, and it seems to work well with the very small subset of features I have, which is essentially just boxes and spheres right now.

You can find it over at godot-jolt/godot-jolt. Here's a short teaser I shared on the contributors chat a few weeks back:

Jolt.mp4

I'll be implementing more of the exposed GDExtension API in the coming weeks/months, assuming no major obstacles, with the hopes of getting as close to feature parity with Godot Physics as possible.

I'll admit I haven't done much research on what the feature overlap is between Godot Physics and Jolt, so I can't say where there will be large gaps in functionality, besides the obvious lack of soft-body physics. So far I've only run into small things, like collision priority not being a thing in Jolt.

I'm very happy to see Jolt adding double-precision, since the lack of such a thing would have been a pretty big asterisk on the feature set of this extension. I'll see about adding that to this extension once he merges it into master.

[jitspoe]

Awesome! Thanks for working on this! I'll definitely be keeping my eye on it.

[jitspoe]

So based on a recent tweet, it seems the reason for not wanting Jolt (aside from relying on a 3rd party library) is that it uses GJK, like bullet, and isn't precise. Seems Jolt has double precision support now, so that's not an argument against it any longer.

I realize there's a desire for precision, but with so many physics libraries going this route, I wonder if we're wishing for something impossible: Generic, precise, and performant. If you look at something like Quake, which uses more precise collision (not an iterative approximation algorithm), it has collision hulls baked into the levels, which limits your collision shapes to predefined boxes, so it's nice and fast, but not generic. I feel like this might be a "pick 2" type of scenario.

[elim2g]

I don't think software freedom is achieved by yelling "do it my way!" at the lead maintainer of your favourite tool.

Of course not, but I feel like there's a fundamental issue here where the direction GodotPhysics is headed is not where gamedevs want it to go. There's a lot of talk of "we don't want to rely on 3rd party libs" and "other solutions are inaccurate" but there's very little being done to catch GP up with the rest of Godot 4.0. I want to be extremely clear that I absolutely love Godot and I would not be contributing to the discussion if I didn't desperately want this project to succeed.

I'm capable of building my own physics engine for my needs and I am indeed doing so - however my concerns here are for the wider audience. I don't think it's reasonable to expect an indie dev or a gameplay programmer to have to build an entire physics engine themselves just to get similar results to what you would expect out-of-the-box from other game engines. This is why I'm raising the points (perhaps with harsher words than required) to try and emphasise just how big these issues are for everyone, not just my niche cases of wanting rock-solid high-speed player movement.

Sokam's first post above yours demonstrates that's not a matter of "rose-tinted glasses", these are games still being played by the most hardcore audience you can imagine. And this is only possible because the physics are incredibly stable, reliable and (in some cases) deterministic. It's a showcase that BSP is not irrelevant due to being old. That being said, I don't believe BSP is the way forward but I do think it can be looked at as an example of what a stable physics engine can look like in motion.

[elvisish]

and I don't see you all rushing to help godot-jolt/godot-jolt become stable and usable, implement a BSP collisions extension, or fix bugs in GodotPhysics.

Honestly, I wish I had the expertise and knowledge to be able to push bug fixes myself. I'm at least hoping that be an end-user of the tool I can be useful in finding the bugs and encouraging discussion on improvements or (if needed) alternatives. The main concern for me right now is 4.0 stable is right around the corner and the current implementation of GP is absolutely not ready for prime time; all of this, perhaps, could have been subverted if Bullet hadn't been removed, although I don't think the implementation of Bullet was the greatest by any means, so maybe it's for the best that we're having this discussion right now.

[azur-wolve]

After reading all that, I see a bit of toxicity in the tone.
If you want the devs to develop the physics (what if I understood correctly is right now their 1st priority), instead of blame, try to be more constructive.

Not sure if the Quake physics is an ideal example, as it has its limitations; @heysokam all the physics stuff I see in those shared links show only static geometry and the player colliding-sliding against it.
But for modern games other stuff is required; soft bodies, non-static geometry, dynamic objects, destructive environments, etc.

In resume, more realistic physics; probably many here just want to create retro games, but Godot is a generic engine, so the aim is to being able to develop modern games with it, rather than only Quake-like games.

I agree with @lawnjelly: most of the "unexpected stuff" I had until now regarding physics was related to inaccuracies derived from float numbers. Maybe using integers would be good for stability, unless there's some advantage using floats/disadvantage when using integers that I'm not aware of.

As personal note.. If Godot would depend on my decisions, I would hire a specialist to help with the Godot Physics, to develop a basis that could be later continued by the devs and contributors, after such hire expiration.

Lets see what happens with the physics, right now its one of the main impediments to develop commercial games with Godot.

[jitspoe]

I think the reason things are getting so heated is due to the fact that Godot 4 is nearing release with a core feature that is fundamentally broken. I don't intend to sound mean, but the reality of the situation is that the physics in their current state are completely unusable and will likely take months to properly fix. There are 3 likely outcomes I see:

1. Godot 4 releases with broken physics, resulting in a lot of frustrated gamedevs and negative press.
2. A 3rd party library is thrown back in to possibly be removed later.
3. Godot 4 release is pushed back in order to allow time for the physics to properly be developed and waiting 4 Godot continues.

Another thing that's frustrating for developers like me is that when I first started using Godot, 4+ years ago, I felt Physics was the weakest part of the engine, and I kept hearing it was going to be worked on, and it kept getting pushed. Then it was going to be a big focus in 4.0, and now here we are with 4.0 in beta, but the physics are worse than they were before. It's difficult to have faith that, after all this time, the physics will magically be fixed right before release.

Again, not trying to be mean. I love Godot and want to see it succeed, but I can't see the release of Godot 4 going well on its current trajectory.

[elvisish]

This is encouraging: https://www.twitter.com/reduzio/status/1609992298179313665

[mihe]

Hello everybody!

I realize this discussion is largely about wanting to get Jolt into Godot as a first-party physics server, so I won't make this too regular of a thing, but I figured I would share some of the progress I've made on my GDExtension since I posted my announcement here.

⚠️ Disclaimer: This is still nowhere near done. This is not usable in real-world applications today, tomorrow, next week or even a month from now. There is still a non-zero chance that this (hobby) project will hit some insurmountable obstacle and never materialize into anything useful.

With that said...

I've managed to add support for all the "standard shapes", meaning SphereShape3D, BoxShape3D, CapsuleShape3D, CylinderShape3D, ConvexPolygonShape3D, ConcavePolygonShape3D and HeightMapShape3D. The only ones missing are the more Godot-specific ones, meaning SeparationRayShape3D and WorldBoundaryShape3D, which I'll get to later down the line. Overall these shapes slotted into Godot pretty well. The only exception would be HeightMapShape3D, which is a bit more restrictive with Jolt, like not allowing height maps that aren't square, among other things.

I've also just finished up all the joints, meaning PinJoint3D, HingeJoint3D, SliderJoint3D, ConeTwistJoint3D and Generic6DOFJoint3D, albeit with some minor kinks I need to sort out, especially on the 6DOF one. The joints didn't slot into Godot as well as I had hoped, so there's one or two parameters in most of them that I couldn't see any way to support, like restitution and damping, but I could be missing something. There's always the option of creating new node types for the joints to better fit with Jolt's interface, but that's for much further down the line. Either way, the basic functionality that you can expect of the joints are there, as you can see in the clip below.

Besides that, I've also added support for a bunch of properties/methods on RigidBody3D as well as some smaller stuff like ray-casting, debug rendering, etc.

The big items going forward are likely going to be Area3D, contact reporting and the remaining physics queries. Beyond that there's a lot of low-hanging fruit that I just haven't bothered with yet.

If you're interested in a more detailed overview of the progress I encourage you to check out the "meta" issues I created in the repository, which you can find here: godot-jolt/godot-jolt#117. Feel free to drop any questions you might have in the repository's Discussions.

I leave you with some clips showcasing all the above mentioned shapes and joints. Note that the rotating slider joint is done using a "motored" Generic6DOFJoint3D.

Shapes.mp4

Joints.mp4

[jitspoe]

My hero!

[timshannon]

Super impressive. I'd love to see the same exact scenes in GD Physics to see a comparison.

[mihe]

I'd love to see the same exact scenes in GD Physics to see a comparison.

Honestly, I'd rather not add any more fuel to the fire, given the vitriol we've seen in this thread already. I don't think this is a particularly useful benchmark for comparing the two implementations, and it wasn't meant to be viewed as such.

I also ran the simulation at a fairly generous 240 hz, for no real good reason other than it being a multiple of the video's frame rate (120).

[mihe]

Hello, lovely people!

A lot has happened since my previous update here, but I'll try to keep this (likely final) update somewhat brief.

Just to get this out of the way, you can now try out Godot Jolt yourself by downloading the release I just published here on GitHub. Be sure to skim through the README there to get a better sense of the compromises involved. Also, C# support for GDExtension is not in a great place right now, so you might run into trouble if you're using that. See this issue for more details.

Since we last spoke I've managed to more or less complete what I (unofficially) dubbed as the first phase of my Jolt extension, where I tried to implement as much of Godot's physics API as possible, without resorting to adding any custom nodes. This was the "Godot Physics feature parity" issue that I linked in my previous update.

The end result of that has been pretty good, I think. Coverage isn't exactly 100%, and probably closer to something like 90%, but I'm overall pleased with how well Jolt has meshed with Godot's physics API. CharacterBody3D is now supported, as well as Area3D, contact reporting, physics queries and a ton more than I can't even remember right now.

I've tried my best to document any missing pieces or other discrepancies in the project's README, but if you happen to run into some that aren't mentioned, please create an issue for it.

To finish up I'd just like to say thank you to everyone here who showed their support. It's funny what power a couple of reaction emojis can have, but this thread alone gave me a much needed morale boost, and I'm not sure I would have gotten to this point without it.

I leave you once and for all with this video of a slightly modified version of GDQuest's RoboBlast demo, being powered by the Jolt physics engine:

RoboBlast.mp4

[outfrost]

Congrats! I'll be sure to check out godot-jolt next time I run into physics trouble.

[azur-wolve]

hi, have been a bit out of Godot 4
whats the current state of Godot Physics?
it has improved since the discussion on this thread?

[elvisish]

hi, have been a bit out of Godot 4

whats the current state of Godot Physics?

it has improved since the discussion on this thread?

A few months ago I had issues with my bounding box catching on seams between gridmap meshes even after the fix in 3.5 that solved this, and it turned out I just needed to increase the safe margin on my KinemeticBody. I've had no issues since, (even walking up slopes into ceilings) but I didn't really notice until recently and this is the only thing I can think of that I changed.

[golddotasksquestions]

Using Godot Jolt means a massive performance improvement compared to Godot Physics when spawning CharacterBody3Ds: godotengine/godot#78761.

Godot Physics by comparison seems completely unuseable, even to Bullet Physics in Godot 3.5.2.

Slideshow appears at
10-40 instances with Godot Physics
250-300 instances with Bullet (Godot3 only)
800+ instances with Godot Jolt (Godot 4.0.3 only)

[Calinou]

For future reference, it's planned to officially endorse using Jolt with Godot: #7308