Physx5 Module for Godot 4+ (Windows & Linux Fully Supported on 4.7.3 rc dev and testing on 4.8)

[uno1982]

Readme:
https://github.com/uno1982/godot/blob/feature/physx5-module/modules/godot_physx/README.md

WIP Fork:
https://github.com/uno1982/godot/tree/feature/physx5-module
Example / Benchmark Repo:
https://github.com/uno1982/godot-physx-example
Overview Video:
Godot 4 + PhysX5 + CUDA Accel

Small preview Snippet of 10k objects

Video.Project.5.mp4

There is plenty of work left to do as I'm still working on fluid dynamics and particles. Currently the lib is externally linked for building and I know there will need to be properly included thirdparty module libs under the similar license to jolt so open to feedback at any point along the way to reduce as much friction as possible to get this into main if considered valuable to others.

Supported as of 9/2/26:

• Static, rigid, kinematic and rigid-linear bodies; box, sphere, capsule, world-boundary, cylinder (approximated), convex hull and concave trimesh collision shapes.

• Per body materials (friction, restitution), linear/angular damping, axis locks, gravity scale, CCD, continuous transform/velocity sync.

• Sleeping with velocity thresholds and time-to-sleep, plus contact stabilization for settling stacks.

• Scene queries: ray, point, shape overlap, motion cast, penetration and closest-point, with collision-mask and RID exclusion filtering.

• Contact reporting to RigidBody3D (body_entered/exited, contact points, impulses) via a custom simulation filter shader.

• Area3D trigger volumes with body enter/exit monitoring, and gravity, damping and wind space overrides applied to overlapping bodies, folded per body in priority order.

• All Joint3D types (pin, hinge, slider, cone-twist, generic 6DOF) with limits and motors; pin uses a linear-locked D6 joint.

• body_test_motion for CharacterBody3D (depenetration recovery plus precise per-shape sweep).

• Optional GPU rigid-body dynamics (scons physx_gpu=yes) via a PhysX CUDA context, GPU broad phase and GPU solver, with a CPU fallback.

Project settings under physics/physx_3d/simulation: solver_type (PGS/TGS), enhanced_determinism, cpu_worker_threads.

UPDATE 10/7/2026
Linux is now fully supported (Please read over the full readme for all build options and updated support as this is changing rapidly)

scons platform=windows target=editor physx_sdk=<path> blast_sdk=<path from --blast>            # CPU
scons platform=windows target=editor physx_sdk=<path> physx_gpu=yes blast_sdk=<path from --blast>  # GPU
scons platform=linuxbsd target=editor physx_sdk=<path> blast_sdk=<path from --blast>           # Linux (CPU)
scons platform=linuxbsd target=editor physx_sdk=<path> physx_gpu=yes blast_sdk=<path from --blast> # Linux (GPU)

I want to personally thank @TheRealKaamy for the PRs and testing on the linux CPU & GPU side.

UPDATE 10/8/2026
@Diginaat is currently cutting releases including the physx5 module and additions like DLSS + DDGI directly off godot main-dev
Again I'd like to thank them personally for the authorship recognition and pulling the module to 4.8-dev so quickly
https://github.com/Diginaat/godot/releases

UPDATE 10/9/2026
First testimonial
Hi Uno — first, thank you for this module. We moved a large Godot game (open world, active-ragdoll characters, boats, vehicles, destruction) from Jolt to godot_physx on Linux (Ubuntu 24.04, GCC 13), RTX 5090, CUDA 12.8.1, with the GPU SDK, Blast and Flow all built. Almost everything worked on the first try, and the Flow / water / cloth / Blast systems are wonderful to build on.
This comes via the way of @kezsonaj and while the above sounds all peach they have been reporting bugs as well as contributing back to make this module a solid foundation to build games on and I'd like to say thank you 🥇

UPDATE 10/15/2026
@gnat is housing the first official pre-release of the direct module editor build (Windows) if anyone wants early access. 🫶 Huge thanks for the early release tags!!!! 🙏
https://github.com/gnat/godot_physx/releases/tag/v2026.10.15

Thanks! ... With ❤️
~Wild Ox Studios

[gnat]

Really surprising to see this!!

As a heavy Godot user, having both Jolt AND PhysX as options in Godot would be a dream for high performance 3D physics- and give us seriously competitive options for all sorts of game types.

• Jolt for deterministic (yet slower) physics.
• PhysX for non-deterministic high performance physics.

PhysX 5 is actually a whole step above what Unreal PhysX has- putting Godot's capabilities above what's in Unreal Engine.

Hope to see this seriously considered!!

[uno1982]

Currently working on fluids just a sneak peek of the early sim. 30k particles is light work

[uno1982]

90k fluid particles with streaming (144htz)

[gnat]

FPS: 144 !!!

Not breaking a sweat.

[uno1982]

[uno1982]

Edtior tooling to visualize the GPU particles realtime at editor time

[uno1982]

Fluid branch getting ready to be merged into the feature branch

[uno1982]

Progress update … cpu vs gpu questions answered, editor tooling for the solver and components. Truely GPU agnostic “non nvidia support overview”
https://www.youtube.com/watch?v=SlxkxvrNdtM

[uno1982]

Borderlands 2 style GPU (with cpu fallback) particle emitters with full collision, wind and rigidbody behavior

2026-09-04.16-07-31.mp4

[robbe1912]

would love to see more of this. fire or smoke sim might also be possible with this?

[uno1982]

in flight

[HeadClot]

I would love to see this happen. Is there support for destruction + tooling for said destruction?

[uno1982]

Stacking Soft bodies ;)

~ ❤️ Wild Ox Studios

[uno1982]

Flex like solving is fully feature complete

https://youtu.be/XyxEbswHKfc

[HeadClot]

Very cool!

[uno1982]

Fluids Update!

https://www.youtube.com/watch?v=D0oquoKaLx4

[uno1982]

Next up granular solving “sand, snow, dirt”

this is a paddle pushing through a stacked granular sim

[DevCurke]

I was just looking into this myself.
Awesome work.

[PhairZ]

Is this proposal even considered to be Merged as a custom solver? I do think it brings a lot to the engine on the 3D side, other than the gpu accelerated sims. Would be very disappointed if it is rejected from merging.

[Schnorg]

I believe there is a maintained fork here:
(https://github.com/Diginaat/godot/tree/nvidia-dlss-physx)

So as far as I understand, you can go use that today and it sounds like they are planning to keep this up to date with major Godot releases.

[uno1982]

https://github.com/gnat/godot_physx/releases/tag/v2026.10.15

I linked it in the discussion head (edit) at the top as there is a pure module release here managed by @gnat

this is still “pre-release” and iteration is happening pretty rapidly once I feel the module is ready for 1.0 and 4.7.3 gets tagged I’ll fall in line and make an official release on the wild ox fork. I’ll then lock into each tagged stable (4.8 tagged stable release etc)

[uno1982]

Given that it makes use of AI tools it cannot be integrated into the engine core as it would violate our guidelines

We also aren't currently looking for another 3D physics backend

Also AI assisted git am patches, PRs, contributions and agentic tooling were kept out of the codebase until the decision for me to maintain it solely was given when I initially queried about being able to find a path into main. I had done everything initially to abide by the AI contribution policy …. Just to give additional context. Each PR is human reviewed and human tested and nothing is accepted without functional test or e2e testing. You can see the dialog on the issues trackers. I personally have no issues with agentic workflows when used by skilled engineers and developers … if a PR solves a bug and it can be reproduced and functionally tested and passes the regression suite then it’s accepted (if not it’s rejected even if it’s 100% human as that alone does not assert good quality or coverage)… let me be clear … I do however have issues with poorly documented code, poorly optimized code or poor implementation quality so please do not open vibe coded PRs expecting them to be merged. You must be utilizing the module in a project and showcase understanding of the request and issues your tracking. This module is an isolated opt in build param scoped and designed as such….Any PR open not isolated to the module or that makes any changes to vanilla Godot or creates dependencies on modified Godot core will be rejected.

An example of tracked cadence and dialogue can be found here.

uno1982/godot-physx-example#1

Thanks 🙏 🫶

[PhairZ]

Given that it makes use of AI tools it cannot be integrated into the engine core as it would violate our guidelines

Not going to agree or disagree here, but wording my question better, is a good tested PhysX implementation welcome upstream if it gets enough testing and reception?

We also aren't currently looking for another 3D physics backend (edit: this is not my position but that of the area maintainers)

Yes, but PhysX is darastically different from Godot's backends (either Jolt or Godot's). It essentially is just a feature expansion.

[uno1982]

Given that it makes use of AI tools it cannot be integrated into the engine core as it would violate our guidelines

Not going to agree or disagree here, but wording my question better, is a good tested PhysX implementation welcome upstream if it gets enough testing and reception?

We also aren't currently looking for another 3D physics backend (edit: this is not my position but that of the area maintainers)

Yes, but PhysX is darastically different from Godot's backends (either Jolt or Godot's). It essentially is just a feature expansion.

I'll do my best to settle concerns here as I've communicated quite a bit initially with the godot maintainers and made decisions early that makes this very simple. Godot vanilla as it stands on the fork is completely unmodified from upstream. Meaning that this module is no different than jolt or godot physics when built via the provided params. Testing has been 1:1 when exporting running projects/games from vanilla godot to the engine with this module built (this is essentially required for proper A/B testing) projects built on this module when pulled back to vanilla godot continue to function with the missing physx classes becoming no op. (again migration from godot+physx to a build without it is literally the same as restarting within godot built with physx and picking jolt instead of physx and is designed as such).

What does this mean in practice? ... it means it really doesn't matter if the module gets adopted upstream and anyone wanting to use Godot + PhysX5 will have a path to simply download a release in the future.

If/when it ever does grow to a place it is reconsidered it will be a clean standalone module and isolated directory structure .... if there is no "if/when" in the modules future then that is fine also... a path to use the module will be available to build yourself or simply grab precompiled. As godot development continues I'll continue to work with vanilla godot gdext abi to try to resolve bottlenecks that keep the module from becoming a performant gdext plugin. There are things there that I can assist with along the way to where the future of this module can be a simple plugin but there are quite a few marshalling, cpu/gpu readback locations and architectural limitations that need to be addressed first. (some of which you can see outlined above) #15471 (reply in thread)

In this way physx is not a "fork" of godot ... its simply an additional module that lives and is developed within a fork of godot ... alongside it with full 1:1 parity of upstream's codebase. modules/godot_physx/ simply lives on top, documents itself and is built via godot's own module check can_build()

The module will be maintained by me regardless of if it spends its entire life outside of main or if it gets pulled upstream and I have to sign some contract or become official godot staff in the process 😄 .... I will state that godot's structure and framework has been a joy and it's been the same diligence and caution being exercised by the maintainers that is responsible for that.

Hope this helps with any concern/confusion

❤️ ~ Wild Ox Studios

[gnat]

We also aren't currently looking for another 3D physics backend

@AThousandShips Cool but IMHO this is a little narrow minded / false equivalency because there's significant pros/cons to each backend depending on the kind of game you're making. Variety is a very good thing for Godot!

Off the top of my head:

Physx advantages:

• Realstic fluids, fire, smoke.. which Jolt does not have. See: Physx5 Module for Godot 4+ (Windows & Linux Fully Supported on 4.7.3 rc dev and testing on 4.8) #15471 (comment) and Physx5 Module for Godot 4+ (Windows & Linux Fully Supported on 4.7.3 rc dev and testing on 4.8) #15471 (comment) ...looks better and is faster than Unreal Engine for real time.
• Real time fracturing/destruction, which Jolt does not have. See: Physx5 Module for Godot 4+ (Windows & Linux Fully Supported on 4.7.3 rc dev and testing on 4.8) #15471 (comment) Again faster than Unreal.

Jolt advantages:

• Deterministic physics for multiplayer. I don't think Physx is fully deterministic.

I'll use the best tool for the game. Jolt was definitely a wonderful upgrade from the old physics but both PhysX and Jolt in this case are well suited to different games made in Godot.

[GoranKovac]

Yeah fluid simulations and destruction is whats the BIG deal here, which wont be getting into godot in not sure what future

[uno1982]

Yeah fluid simulations and destruction is whats the BIG deal here, which wont be getting into godot in not sure what future

Just a FYI.... Blast and Flow are technically solver agnostic. Blast's core is just a fracture graph, and Flow is its own GPU grid sim. The catch is integration, much like Blast or Flow on Chaos in UE5 (I have plugins for those too). You can get these libs working outside the module, and I'm looking into GDExtension options for godot plugins myself, but you lose what makes them fast/performant here .... direct access to the solver (contact impulses for impact damage, cached hull cooking, PhysX GPU dynamics for debris) and to Godot's render internals (Flow composites through RenderingDevice and the compositor, which GDExtension doesn't fully expose yet).

I've worked with PhysX for over a decade, in Unreal and other engines, so performance is front and center in everything I do. If the implementation constraint negates the benefit, the approach loses its value. When people say "this is faster than Unreal", it's because it's done differently: built into Godot's physics and rendering servers, native to its RenderingDevice (Vulkan / D3D12).

For now I must remain focused on the priority..... core behavior at parity with Jolt (done, with a few documented differences), plus the things only PhysX 5 brings, stable and value-adding: skinned cloth, the vehicle classes, liquid sim, water bodies, heightmap/landscape support, destruction actors, the chunk emitter, and so on. That also includes editor tooling that actually empowers developers to utilize them.

[uno1982]

Liquid Solver Screenspace rendering & Flow Light Scatter Update is now Live.

https://www.youtube.com/watch?v=mcTw_bwEx-g

❤️ ~ Wild Ox Studios

[uno1982]

WIP of physxLightShafts3D and flow's update to occlude lights ...coming soon

2026-10-21.19-07-39.mp4

2026-10-21.19-49-47.mp4

[uno1982]

Oh yeah .. and mobile renderer just for the fun of it ❤️

2026-10-21.20-05-33.mp4

[gnat]

For mobile renderer this is just wow.... 👏

[uno1982]

Continued WIP ... Coming soon! Lens Dirt, Halo and Flare (realtime updates via emissives and flow)

2026-10-23.02-29-32.mp4

2026-10-23.02-56-04.mp4

Emissives (including flow) push into the compositor for dynaimic flare and halo updates

❤️ ~ Wild Ox Studios

[johnlogostini]

OK, I am confused. What in the world am I looking at! Is this PostWorks?, and is that also bundled with PhysX this?, or are those two separate effects? Also, are those NVIDIA’s old volumetric light shafts or screen-space occlusion shaders?

Either way, it looks awesome, and you’re doing amazing!

[uno1982]

OK, I am confused. What in the world am I looking at! Is this PostWorks?, and is that also bundled with PhysX this?, or are those two separate effects? Also, are those NVIDIA’s old volumetric light shafts or screen-space occlusion shaders?

Either way, it looks awesome, and you’re doing amazing!

haha man ... I love meeting a fellow dev/engineer that name drops libraries and papers and understands where these approaches come from ❤️

[uno1982]

Next Up WIP (Please forgive the construction) PhysX (Proxy Traced GI) or as I'll coin it PXTGI

2026-10-23.14-34-21.mp4

[uno1982]

Emissive support incoming ... and no its not screenspace .... it leans on a hybrid of screenspace and worldspace "physX5 collider prims" nothing really needs to ever leave the GPU/render server and cost about half the cost of SDFGI with none of the camera update SDF marshalling cost. So yes ... the module will have its own "extremely easy to configure" GI solution. No baking, No cascade cell sizes, no "this thing doesn't work dynamically" and most importantly GPU agnostic and isolated and native to the module (needs PhysX5 shaders/prims to function) without any changes to core godot.

[gnat]

I don't think people are grasping how cool this is.

Real time alternative to SDFGI / VoxelGI with 2x performance.. never leaves the GPU!!!

Nice work!!!! Definitely want to see more before/after sample scenes! 🥳

Ya'll are gonna want to be aware this exists: @reduz @clayjohn @AThousandShips @passivestar @FR3NKD @KenneyNL

Shipping to Steam Deck? Game changer.

Likely the highest performance real time GI solution of this quality on Steam Deck right now.

Unreal Engine Lumen struggles like hell to even hit 30 FPS without heroics / gymnastics.

[uno1982]

Dynamic update motion stability of emissives

2026-10-24.01-45-52.mp4

[uno1982]

And today officially marks the birth of a new SWRT Godot GI Solution! PXTGI (Physx5 proxy traced GI) ❤️

https://www.youtube.com/watch?v=PNen3SCoy3A

[gnat]

Windows build with PXTGI here! https://github.com/gnat/godot_physx/releases/tag/v2026.10.25

[Alexofp]

proxy traced? Means its tracing against the collision data? I only see boxes/spheres in the video, can it trace proper meshes? Just curious about the limitations. It does look very clean

[uno1982]

proxy traced? Means its tracing against the collision data? I only see boxes/spheres in the video, can it trace proper meshes? Just curious about the limitations. It does look very clean

Just keep in mind this is “experimental” and very very early and yes it’s tracing against proxies for worldspace bvh/sha generation and uses radiance caching and screenspace for “everything” even if it doesn’t have a proxy so technically all surfaces work as outlined in the video “blast fractures worked there”

[uno1982]

[gnat]

So you can switch between SDFGI and PXTGI in the demo and the results are night and day.. 😅

PXTGI IS AMAZING FOR GODOT 🤯 🔥

This is literally a faster Lumen for Godot. Holy cow.

SDFGI...a bit of a hot mess in comparison.

[JekSun97]

I believe this project features not only advanced PhysX 5 physics, but now also advanced graphics!

This fork could be called the "Godot AAA Engine." 😁

I think the Godot development team significantly underestimates the potential of this project. We could spend five years waiting for AAA-level capabilities to arrive in Godot—resorting to all sorts of convoluted user-side workarounds—or we could simply embrace what we have right here. Any existing limitations can be bypassed or fixed, provided there’s a willingness to do so—for instance, by refactoring the code (if, say, it contains a lot of flawed AI-related code).
I honestly can’t imagine what Godot Engine 5 could possibly offer to surprise us by the time it’s released, if it doesn’t include the features already present in this project.

[jcostello]

How do I test this? I build the source from https://github.com/gnat/godot_physx/releases/tag/v2026.10.25

[uno1982]

Just download the zip for windows it’s built for you

[jcostello]

I have linux. I built it from source. But I mean, I don't see a GI node to add to my scene and test

[uno1982]

If your building from source use my fork branch linked at the top. Gnat cuts prereleases but if your building yourself and you want the Experimental stuff you’ll want to be directly off the module feature branch “my fork”

https://github.com/uno1982/godot/tree/feature/physx5-module

[gnat]

New Windows build with PXTGI + Flow + Blast here: https://github.com/gnat/godot_physx/releases/tag/v2026.10.26

(Commit #a086081)