Closes godotengine/godot-proposals#7308.
This pull request adds a new engine …module (found under `modules/jolt_physics`) which integrates [Jolt Physics][jolt], a 3D physics engine developed by Jorrit Rouwe (@jrouwe) with a focus on games and VR applications, used in titles such as Horizon Forbidden West.
Users of this new module should (generally, but not always) be able to expect better physics performance, both in terms of CPU performance and simulation stability, when compared to Godot Physics.
This new module is a port of the [Godot Jolt][gdj] extension, developed by myself over the past two years, in large part as a personal project, but with the last year (including this port) being sponsored by [W4 Games][w4]. I've also received a significant amount of assistance and contributions from @jrouwe during this development, which I'm very grateful for. In fact, several major features have been added to Jolt largely to cater to the needs of Godot.
> [!WARNING]
> Note that while this code has gone through a fair amount of battle-testing as part of the Godot Jolt extension there have been non-trivial refactorings done as part of this port that have not been tested much at all. As such, this module should be considered experimental for now. This module is also not at feature parity with Godot Physics just yet, nor at feature parity with the Godot Jolt extension either.
This does **not** replace Godot Physics as the default 3D physics engine. You will need to opt in by setting the `physics/3d/physics_engine` project setting to `Jolt Physics`.
## Notable differences to Godot Physics
While the goal is to have this new module be a drop-in replacement for Godot Physics (within reason), Jolt inherently differs from it in a number of ways, which means that it is unlikely that you will see the exact same behavior when switching between the two. There are also several higher-level decisions taken within the module that deviate further from how Godot Physics does things.
### `Area3D` and static bodies
<details><summary>[Click to expand/collapse]</summary>
<p>
When using Jolt, `Area3D` will not detect overlaps with `StaticBody3D` (nor a `RigidBody3D` frozen with `FREEZE_MODE_STATIC`) by default, for performance reasons. If you have many/large `Area3D` overlapping with complex static geometry, such as `ConcavePolygonShape3D` or `HeightMapShape3D`, you can end up wasting a significant amount of CPU performance without realizing it.
For this reason this behavior is opt-in through the project setting `physics/jolt_physics_3d/simulation/areas_detect_static_bodies`, with the recommendation that you set up your collision layers/masks in such a way that only the relevant `Area3D` are able to detect collisions with static bodies.
This should probably be made into an `Area3D` property instead, through something like what's been suggested [here][props].
</p>
</details>
### Joint properties
<details><summary>[Click to expand/collapse]</summary>
<p>
The current interfaces for the 3D joint nodes, which seem to be derived from the Bullet Physics library, don't quite line up with the interface of Jolt's own joints. As such, there are a number of joint properties that are not supported, mainly ones related to configuring the joint's soft limits.
The unsupported properties are:
- `PinJoint3D`: `bias`, `damping`, `impulse_clamp`
- `HingeJoint3D`: `bias`, `softness`, `relaxation`
- `SliderJoint3D`: `angular_*`, `*_limit/softness`, `*_limit/restitution`, `*_limit/damping`
- `ConeTwistJoint3D`: `bias`, `relaxation`, `softness`
- `Generic6DOFJoint3D`: `*_limit_*/softness`, `*_limit_*/restitution`, `*_limit_*/damping`, `*_limit_*/erp`
Currently an error is emitted if you set these properties to anything but their default values.
In the Godot Jolt extension I exposed alternative joint nodes that better matched Jolt's interface, but these have not been included in this module. Instead, the above mentioned properties should probably be removed and replaced by properties more fitting for Jolt, through something like what's been suggested [here][props].
</p>
</details>
### Single-body joints
<details><summary>[Click to expand/collapse]</summary>
<p>
You can, in Godot, omit one of the joint bodies for a two-body joint and effectively have "the world" be the other body. However, the node path that you assign your body to (`node_a` vs `node_b`) is ignored. Godot Physics will always behave as if you assigned it to `node_a`, and since `node_a` is also what defines the frame of reference for the joint limits, you end up with inverted limits and a potentially strange limit shape, especially if your limits allow both linear and angular degrees of freedom.
This is arguably a bug and should be changed. This is also not how single-body joints behaves with Bullet in Godot 3, which behaves as if you assigned the body to `node_b` instead. It's not clear why this changed in Godot 4.
For this reason this module will, like Bullet in Godot 3, behave as if you assigned the body to `node_b` instead, with `node_a` representing "the world".
There is a project setting called `physics/jolt_physics_3d/joints/world_node` that lets you toggle this behavior, if you need compatibility for an existing project.
</p>
</details>
### Collision margins
<details><summary>[Click to expand/collapse]</summary>
<p>
Jolt (and other similar physics engines) uses something that Jolt refers to as "convex radius" to help improve the performance and behavior of the types of collision detection that Jolt relies on for convex shapes. Other physics engines (Godot included) might refer to these as "collision margins" instead. Godot exposes these as the `margin` property on every `Shape3D`-derived class, as a leftover from the Bullet integration in Godot 3, but Godot Physics itself does not use them for anything.
What these collision margins sometimes do in other engines (as described in Godot's documentation) is effectively add a "shell" around the shape, slightly increasing its size while also rounding off any edges/corners. In Jolt however, these margins are first used to shrink the shape, and then the "shell" is applied, resulting in edges/corners being similarly rounded off, but without increasing the size of the shape.
To prevent having to tweak this `margin` property manually, since its default value can be problematic for smaller shapes, this module exposes a project setting called `physics/jolt_physics_3d/collisions/collision_margin_fraction` which is multiplied with the smallest axis of the shape's AABB to calculate the actual margin. The `margin` property of the shape is then instead used as an upper bound.
These margins should, for most use-cases, be more or less transparent, but can sometimes result in odd collision normals when performing shape queries. You can lower the above mentioned project setting to mitigate some of this, including setting it to `0`, but too small of a margin can also cause odd collision results, so is generally not recommended.
</p>
</details>
### Compound shapes
<details><summary>[Click to expand/collapse]</summary>
<p>
Compound shapes (i.e. bodies with more than one shape) are implemented differently from Godot Physics.
Jolt offers the choice of two compound shapes, one called `MutableCompoundShape` and one called `StaticCompoundShape`. The former trades in runtime performance for faster construction/modification time, and vice versa for the latter.
Godot Physics maps closer to Jolt's `MutableCompoundShape`, but I decided to go with `StaticCompoundShape` for this implementation, as it simplified things a bit (with being able to discard and rebuild the whole thing when modified) and I figured more people would benefit from the improved runtime performance as opposed to mutation performance.
To mitigate the cost of this potentially expensive rebuild, I made it so that shape changes are only ever "committed" to Jolt when the body has entered into a scene tree. This means that you can make shape changes (including adding/removing shapes) very quickly so long as the body isn't attached to the scene tree. However, if you do in fact add the body to a scene tree, and then start adding/removing/changing shapes on the body, you can end up with worse performance than Godot Physics. This is prominently visible in the "Voxel Game" demo project, as one example.
The plan I have in mind for this (discussed in jrouwe/JoltPhysics#1165) is to replace `StaticCompoundShape` with a custom compound shape that wraps `StaticCompoundShape`, but which will always defer its building/committing only until absolutely necessary, meaning either right before a simulation step or when performing queries against the body.
If the use of `StaticCompoundShape` within this new custom compound shape still ends up being a problem for some use-cases it would likely be trivial to expose some setting or property that lets you use `MutableCompoundShape` instead.
</p>
</details>
### Scaling shapes/bodies/queries
<details><summary>[Click to expand/collapse]</summary>
<p>
Godot Physics supports scaling the transform of collision shapes, shape queries, as well as static and kinematic bodies, meaning `StaticBody3D`, `CharacterBody3D`, `AnimatableBody3D` and frozen `RigidBody3D`. It does not however support scaling simulated/dynamic bodies, such as a non-frozen `RigidBody3D`, and will effectively discard any such scaling, instead treating it as `(1, 1, 1)`.
Jolt does however support scaling everywhere, and I've tried my best to utilize that, which means that `RigidBody3D` will support scaling when using Jolt, despite the warning shown on the node currently.
Jolt also supports non-uniform scaling, so long as the inherent primitive shape is preserved. For example, you can scale a cylinder along its height axis but not along its other axes. You will however currently see warnings on the shape node when doing this, due to Godot Physics not supporting this.
Since invalid scaling can cause a number of weird artifacts, and sometimes outright crash the simulation, there are runtime error checks that "sanitize" all scaling to be valid for that particular shape arrangement, and then reports an error if the difference is above an arbitrary threshold. These errors have however proven to be a bit frustrating for some users, who might not care about the sometimes minor corrections that this error-checking applies, so this likely needs a different approach.
</p>
</details>
### Shape-casting
<details><summary>[Click to expand/collapse]</summary>
<p>
Due to Godot having a "safe" and "unsafe" fraction in the results of `cast_motion` (and `ShapeCast3D`), meaning the distances at which the cast shape was found to be colliding and not colliding respectively, it was not viable to rely on Jolt's own shape-casting (which uses conservative advancement) to implement `cast_motion`. Instead `cast_motion` is implemented with a binary search, similar to how Godot Physics does it.
However, in Godot Physics this binary search is hardcoded to 8 steps, which tends to result in quite jittery output over even moderate distances. With Godot Jolt (and consequently this module) I chose to instead dynamically calculate the number of steps based on the cast distance, aiming for roughly millimeter precision, and then clamp it between 4 and 16 steps, which seems to have worked out well.
This does however mean that `cast_motion` will technically, when using Jolt, cost more CPU performance the farther you cast the shape.
Note that this also applies to `body_test_motion`, and consequently `test_move`, `move_and_collide` and `move_and_slide`.
</p>
</details>
### Baumgarte stabilization
<details><summary>[Click to expand/collapse]</summary>
<p>
Jolt employs a technique in its solver called Baumgarte stabilization, which is meant to mitigate constraint drift within the simulation, resulting in a more stable simulation. This technique can however result in some artifacts, like piles of bodies not separating as quickly as one might expect.
The strength of this stabilization can be tweaked using the project setting `physics/jolt_physics_3d/simulation/baumgarte_stabilization_factor`. Setting this project setting to `1.0` will ~~effectively disable the technique~~ resolve any position error (e.g. penetration) in a single simulation step. Doing so will however result in a simulation that is more unstable.
EDIT: It was pointed out that Godot Physics also utilizes this technique, but differs from Jolt in that it also updates the velocities after applying the Baumgarte stabilization. Not updating the velocities help with preventing overshoot, but is also what results in a slower error correction.
</p>
</details>
### Motion queries (`move_and_slide`, etc.)
<details><summary>[Click to expand/collapse]</summary>
<p>
Physics servers in Godot are meant to implement the `PhysicsServer3D.body_test_motion` method, which in turn powers methods like `PhysicsBody3D.test_move`, `PhysicsBody3D.move_and_collide` and `CharacterBody3D.move_and_slide`, which are largely meant to be used for moving player characters around.
`PhysicsServer3D.body_test_motion` is split into three parts, the first being depenetration (called "recovery" in Godot), the second being a shape-cast from the "recovered" position, and the third being the actual collision check, at the "unsafe" fraction of the shape-cast.
The "recovery" step in Godot Physics is hardcoded to always do 4 iterations with 40% depenetration per iteration. I figured these constants might be useful to expose, so when using this module they can be configured in the project settings as `physics/jolt_physics_3d/motion_queries/recovery_iterations` and `physics/jolt_physics_3d/motion_queries/recovery_amount` respectively.
The implementation of `PhysicsServer3D.body_test_motion` in this module also differs slightly from the Godot Physics implementation, as replicating the Godot Physics version resulted in a prohibitive amount of ghost collisions for `move_and_slide`.
The discrepancies are as follows:
1. There is no `TEST_MOTION_MIN_CONTACT_DEPTH_FACTOR`.
2. There is no epsilon added to the safe margin during recovery.
3. Contacts with normals that are not opposing the motion vector are discarded from the final collision check.
While these discrepancies do seem to result in less ghost collisions when using Jolt, they also introduce new problems:
1. `move_and_slide` is generally slower than in Godot Physics, due to `CharacterBody3D::_snap_on_floor` triggering on every call.
2. `CharacterBody3D` will not report wall collisions unless you're moving towards them.
It's not clear to me how to fix these issues, but I suspect they will require changes to `move_and_slide` on the scene side of things.
</p>
</details>
### Ghost collisions
<details><summary>[Click to expand/collapse]</summary>
<p>
Jolt employs two techniques to mitigate ghost collisions, meaning collisions with internal edges of shapes/bodies.
The first technique, called "active edge detection", marks edges of triangles in `ConcavePolygonShape3D` or `HeightMapShape3D` as either "active" or "inactive", based on the angle to the neighboring triangle. When a collision happens with an inactive edge the collision normal will be replaced with the triangle's normal instead, to lessen the effect of ghost collisions.
The angle threshold for this active edge detection is configurable through the project setting `physics/jolt_physics_3d/collisions/active_edge_threshold`.
The second technique, called "enhanced internal edge removal", instead adds runtime checks to detect whether an edge is active or inactive, based on the contact points of the two bodies. This has the benefit of applying not only to collisions with `ConcavePolygonShape3D` and `HeightMapShape3D`, but also edges between any shapes within the same body.
Enhanced internal edge removal can be toggled on and off for the various contexts to which it's applied, using the `physics/jolt_physics_3d/*/use_enhanced_internal_edge_removal` project settings.
</p>
</details>
### Memory usage
<details><summary>[Click to expand/collapse]</summary>
<p>
Jolt uses a stack allocator for temporary allocations within its simulation step. This stack allocator requires allocating a set amount of memory up front, which can be configured using the `physics/jolt_physics_3d/limits/temporary_memory_buffer_size` project setting.
Jolt also makes use of aligned allocations for some of its memory usage, which it acquires through function pointers that the implementer assigns. Aligned allocations were recently added to Godot in the form of `Memory::alloc_aligned_static`, `Memory::realloc_aligned_static` and `Memory::free_aligned_static`, which have all been hooked up to Jolt. However, these aligned allocation functions don't currently touch `Memory::mem_usage`, which means that some of Jolt's memory won't be tracked, and thus the performance monitors in Godot won't be accurate.
</p>
</details>
### Ray-cast face index
<details><summary>[Click to expand/collapse]</summary>
<p>
The `face_index` property returned in the results of `intersect_ray` and `RayCast3D` will by default always be `-1` with Jolt, with a project setting (`physics/jolt_physics_3d/queries/enable_ray_cast_face_index`) to enable them. The reason for this being that Jolt does not store these indices, and for them to be stored we need to enable the per-triangle userdata, which adds about 25% extra memory usage to the underlying Jolt implementation of `ConcavePolygonShape3D`.
This should maybe be made into a `ConcavePolygonShape3D` property instead, through something like what's been suggested [here][props].
</p>
</details>
### Kinematic `RigidBody3D` contacts
<details><summary>[Click to expand/collapse]</summary>
<p>
When using Jolt, a `RigidBody3D` frozen with `FREEZE_MODE_KINEMATIC` will by default not report contacts from collisions with other static/kinematic bodies, for performance reasons, even when setting a non-zero `max_contacts_reported`. If you have many/large kinematic bodies overlapping with complex static geometry, such as `ConcavePolygonShape3D` or `HeightMapShape3D`, you can end up wasting a significant amount of CPU performance without realizing it.
For this reason this behavior is opt-in through the project setting `physics/jolt_physics_3d/simulation/generate_all_kinematic_contacts`.
This should probably be made into an `RigidBody3D` property instead, through something like what's been suggested [here][props].
</p>
</details>
### Contact impulses
<details><summary>[Click to expand/collapse]</summary>
<p>
Jolt is not able to provide any impulse as part of its contact data, due to how it orders its simulation step, and instead provides a helper function for estimating what the impulse would be based on various parameters. While this is probably fine for most use cases, like emitting a sound based on how hard something collided, it won't be accurate if a body is colliding with multiple bodies during a simulation step.
</p>
</details>
### `Area3D` and `SoftBody3D`
<details><summary>[Click to expand/collapse]</summary>
<p>
This module does not currently support any interactions between `SoftBody3D` and `Area3D`, such as overlap events, or the wind properties found on `Area3D`. Support for this has been added to Jolt recently, and @jrouwe also did some work towards the extension part of it, but it has not been included in this pull request.
</p>
</details>
### `ConvexPolygonShape3D`
<details><summary>[Click to expand/collapse]</summary>
<p>
Godot Physics currently skips calculating a proper center-of-mass and inertia for `ConvexPolygonShape3D`, and instead always uses the shape's local position as its center of mass, while crudely estimating the inertia. Jolt on the other hand does calculate a more accurate center-of-mass and inertia for them. As a result a non-frozen `RigidBody3D` with such a shape in it can behave differently when comparing the two engines.
</p>
</details>
### `WorldBoundaryShape3D`
<details><summary>[Click to expand/collapse]</summary>
<p>
`WorldBoundaryShape3D`, which is meant to represent an infinite plane, is implemented a bit differently in Jolt compared to Godot Physics. Both engines have an upper limit for how big the effective size of this plane can be, but this size is much smaller when using Jolt, in order to avoid precision issues.
You can configure this size using the `physics/jolt_physics_3d/limits/world_boundary_shape_size` project setting.
</p>
</details>
### Axis-locking
<details><summary>[Click to expand/collapse]</summary>
<p>
The `PhysicsBody3D.axis_lock_*` properties in Godot Physics are implemented by simply zeroing out the velocities for the selected axes. Jolt instead implements these by calculating a new inverse mass/inertia, similar to how `RigidBody3D.lock_rotation` works in Godot Physics, which seems to better mitigate energy loss during simulation.
However, Jolt does not allow locking all axes, meaning both linear and angular axes, and an error will be emitted from this module when trying to do so, with the recommendation that you instead freeze the body entirely. While this is a simple enough workaround for `RigidBody3D`, you cannot currently freeze a `PhysicalBone3D`, so if you want to lock all axes of a `PhysicalBone3D` you're forced to resort to calling `PhysicsServer3D.body_set_mode` yourself.
</p>
</details>
## Notable differences to Godot Jolt
While this module is largely a straight port of the Godot Jolt extension, with a lot of cosmetic changes, there are a few things that are different.
### Project settings
<details><summary>[Click to expand/collapse]</summary>
<p>
All project settings have been moved from the `physics/jolt_3d` category to `physics/jolt_physics_3d`.
On top of that, there's been some renaming and refactoring of the individual project settings as well. These include:
- `sleep/enabled` is now `simulation/allow_sleep`.
- `sleep/velocity_threshold` is now `simulation/sleep_velocity_threshold`.
- `sleep/time_threshold` is now `simulation/sleep_time_threshold`.
- `collisions/use_shape_margins` is now `collisions/collision_margin_fraction`, where a value of 0 is equivalent to disabling it.
- `collisions/use_enhanced_internal_edge_removal` is now `simulation/use_enhanced_internal_edge_removal`.
- `collisions/areas_detect_static_bodies` is now `simulation/areas_detect_static_bodies`.
- `collisions/report_all_kinematic_contacts` is now `simulation/generate_all_kinematic_contacts`.
- `collisions/soft_body_point_margin` is now `simulation/soft_body_point_radius`.
- `collisions/body_pair_cache_enabled` is now `simulation/body_pair_contact_cache_enabled`.
- `collisions/body_pair_cache_distance_threshold` is now `simulation/body_pair_contact_cache_distance_threshold`.
- `collisions/body_pair_cache_angle_threshold` is now `simulation/body_pair_contact_cache_angle_threshold`.
- `continuous_cd/movement_threshold` is now `simulation/continuous_cd_movement_threshold`, but expressed as a fraction instead of a percentage.
- `continuous_cd/max_penetration` is now `simulation/continuous_cd_max_penetration`, but expressed as a fraction instead of a percentage.
- `kinematics/use_enhanced_internal_edge_removal` is now `motion_queries/use_enhanced_internal_edge_removal`.
- `kinematics/recovery_iterations` is now `motion_queries/recovery_iterations`, but expressed as a fraction instead of a percentage.
- `kinematics/recovery_amount` is now `motion_queries/recovery_amount`.
- `queries/use_legacy_ray_casting` has been removed.
- `solver/position_iterations` is now `simulation/position_steps`.
- `solver/velocity_iterations` is now `simulation/velocity_steps`.
- `solver/position_correction` is now `simulation/baumgarte_stabilization_factor`, but expressed as a fraction instead of a percentage.
- `solver/active_edge_threshold` is now `collisions/active_edge_threshold`.
- `solver/bounce_velocity_threshold` is now `simulation/bounce_velocity_threshold`.
- `solver/contact_speculative_distance` is now `simulation/speculative_contact_distance`.
- `solver/contact_allowed_penetration` is now `simulation/penetration_slop`.
- `limits/max_angular_velocity` is now stored as radians instead.
- `limits/max_temporary_memory` is now `limits/temporary_memory_buffer_size`.
There might be some discussion to be had with regards to migrating the settings values for projects who have previously been relying on the extension.
</p>
</details>
### Joint nodes
<details><summary>[Click to expand/collapse]</summary>
<p>
The joint nodes that are exposed in the Godot Jolt extension (`JoltPinJoint3D`, `JoltHingeJoint3D`, `JoltSliderJoint3D`, `JoltConeTwistJoint3D` and `JoltGeneric6DOFJoint`) have not been included with this module.
Instead of exposing bespoke joint nodes, the existing joint node interfaces should be modified by the physics server, through something like what's been suggested [here][props].
</p>
</details>
### Thread-safety
<details><summary>[Click to expand/collapse]</summary>
<p>
Unlike the Godot Jolt extension, this module does have experimental thread-safety, including support for the `physics/3d/run_on_separate_thread` project setting. This is achieved by utilizing the same wrapper server that's used by Godot Physics, called `PhysicsServer3DWrapMT`, as well as introducing a mutex around the rebuilding of shapes, since concurrent shape-casts could otherwise trigger a race condition.
This has however not been tested very thoroughly, so should be considered experimental.
</p>
</details>
### Query performance
<details><summary>[Click to expand/collapse]</summary>
<p>
The Godot Jolt extension utilizes a custom container (typically referred to as an "inline vector" or "small vector") in order to avoid heap allocations for physics queries that return more than a single hit, meaning `intersect_point`, `intersect_shape`, `collide_shape`, `get_rest_info`, `cast_motion`, `body_test_motion`, `test_move`, `move_and_collide` and `move_and_slide`.
For the sake of simplifying this port I chose to just use `JPH::Array` for the query collectors instead, which means that these queries will now always allocate on the heap, likely making them noticeably slower.
It should be trivial to make some bespoke container for the query collectors that behaves like an inline/small vector.
</p>
</details>
### Debug renderer
<details><summary>[Click to expand/collapse]</summary>
<p>
Jolt provides an interface called `JPH::DebugRenderer` for rendering its view of the physics simulation. In the Godot Jolt extension I expose this as a custom `GeometryInstance3D` node called `JoltDebugGeometry3D`, which proved to be very useful during development, but I figured this module should probably take a different approach, so I have omitted that code.
</p>
</details>
### Debug snapshots
<details><summary>[Click to expand/collapse]</summary>
<p>
The Godot Jolt extension has the ability to generate what Jolt refers to as "snapshots", where it serializes the state of the physics simulation to a file. These can then be loaded in Jolt's own `Samples` application, to debug issues more closely there, without needing to deal with Godot itself, which has proved to be quite useful when reporting issues upstream to Jolt.
The code for this is technically included with this module, and can be found as `JoltPhysicsServer3D::dump_debug_snapshots`, but it wasn't clear to me how to best expose this, so I've left it unexposed for now.
</p>
</details>
## Things left to do
Just to give people an idea about the state of this module, and perhaps encourage future contributions if/when this pull request is merged, here is a rough copy of my to-do list:
### Must-have
- Add the ability for physics servers to add/remove/change node properties.
- Using the ability to modify node properties, change the joint interfaces to better match Jolt.
- Using the ability to modify node properties, move some of the project settings to instead be per-body/per-shape properties.
- Add support for interactions between `Area3D` and `SoftBody3D`.
- Implement the deferred compound shape mentioned above.
- Add memory usage tracking for aligned allocations.
- Add support for freezing `PhysicalBone3D`.
- Investigate issues with motion queries mentioned above.
- Resolve frustrations with invalid scaling.
### Nice-to-have
- Add migration for the project settings.
- ~~Get rid of heap allocations in shape queries when requested hits are less or equal to default.~~
- Expose Jolt's debug rendering somehow (maybe as a viewport mode?).
- Expose Jolt's debug snapshots somehow, if only just for `dev_build`.
- Resolve discrepancy with single-body joints mentioned above.
- ~~Get rid of the body accessors in `jolt_body_accessor_3d.h`, in favor of just storing the `JPH::Body*` in `JoltObject3D`.~~
- ~~Try remove the use of `JPH::PhysicsSystem::GetBodies`, to avoid the overhead of iterating over static/sleeping bodies.~~
- Maybe consider adding a temporary memory allocator that doesn't pre-allocate memory.
- Link Jolt's `Jolt.natvis` file in MSVC builds for easier debugging.
## What about the extension?
If/when this pull request is merged, the Godot Jolt extension will officially be considered to be in maintenance mode going forward, with only bug fixes backported to it, but so long as this engine module doesn't have full feature parity with the extension there will be new releases of the extension to ensure that projects relying on its additional features can continue to function.
If/when this engine module reaches full feature parity with the extension then the extension will be discontinued and its GitHub repository archived.
## Attribution
In the interest of not cluttering every file in this new module with the copyright notice of Godot Jolt, as required by its MIT license, consider this my permission to omit it entirely. I have obtained permission from the applicable copyright holders (@jrouwe) to do so as well.
---
(This port is based on godot-jolt/godot-jolt@8f1212e19a1bdc76ce34b5ddcfabbfd6e409ef9c, meaning the latest commit of Godot Jolt as of writing this.)
[jolt]: https://github.com/jrouwe/JoltPhysics
[gdj]: https://github.com/godot-jolt/godot-jolt
[w4]: https://www.w4games.com/
[props]: https://github.com/godotengine/godot-proposals/issues/10438#issuecomment-2306922209
