Physics test framework & PhysX evaluation

[pouleyKetchoupp]

# Describe the project you are working on:
This is a proposal for the engine, not related to a specific game project.

I have experience with physics engines integration in general and with PhysX. I'm interested in contributing to the evaluation of PhysX in Godot.

# Describe the problem or limitation you are having in your project:
n/a

# Describe the feature / enhancement and how it helps to overcome the problem or limitation:
I'm opening this proposal to discuss about building a test framework for 3D physics and using it for evaluating PhysX for Godot 4.0.

1. Physics test framework

This part is independent from the physics engine we use, so it can be useful for Godot Physics and Bullet as well.

This framework would have a series of tests that can be used for different purposes:
-- Functional tests to check for regressions and compare behavior between physics engines
-- Stress tests to evaluate & compare performance between physics engines
-- Technical demos to show the engine capabilities

It probably doesn't require changes in the engine core, and can be as simple as a Godot project with different scenes for each test, and a menu to switch between them easily or execute a series of tests.

The demo projects repository seems like a good place for this project.

Functional tests are used to visualize and validate the physics engine's behavior in specific scenarios. It can optionally include some checks and output whether they pass or fail.
e.g: effect of physics materials, character controller movements, different types of ray/shape casts

Stress tests output timings in different situations that can be considered critical to check the physics engine's performance.
e.g: exploding pile of dynamic bodies, add/remove lots of bodies at once, execute a batch of ray/shape casts

Technical demos can be interactive and are used to show specific engine features.
e.g: vehicle, ragdoll, soft body

2. PhysX evaluation

The physics tests described in the previous part can be used as a tool to compare physics engines and evaluate PhysX.

Version: probably last stable - 4.1

PhysX integration can be done step by step:
First, only the minimum required for the evaluation itself (rigid bodies with basic shape types, character controller, joints,...)
Then, implement more features if the tests show it's worth going further with the integration.

Evaluation criteria:
General performance
Feature completeness (does it allow implementing all the existing features?)
Feature improvements (can it help solving issues or improving existing features?)

Potential improvements:
Better performance (to be tested)
Improved joints stability (to be tested)
Support for baking collision shapes offline (faster loading & optimized for performance)
Support for per-shape & per-triangle physics materials
Support for GPU-based simulation
Well-documented API
Record/replay debugging using PVD

# Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Physics tests don't have to be part of the engine core.

PhysX will be integrated in a similar way as Bullet, by implementing a physics server as a separate module within the engine.
Edited:
PhysX will be implemented as a physics server, and released as a separate plug-in using GDNative.

Work in progress branch for PhysX integration as a core module:
https://github.com/nekomatata/godot/tree/_wip_physx

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

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

[akien-mga]

Pasting some comments from IRC:

17:37 <reduz> PouleyKetchoup: my plan is to eventually fix the Godot physics engine, modernize it a bit and get it to work properly
17:38 <reduz> PouleyKetchoup: and then make sure physics servers can be made in GDNative
17:38 <reduz> PouleyKetchoup: so we can have Bullet or PhysX as pluggable
17:39 <reduz> PouleyKetchoup: but if you really need it, and want to try making it a module for the time being, it should be fine, could be ported later to gdnative
17:39 <Akien> PouleyKetchoup: aside from what reduz said, I think part 1 is obviously a good idea (and should likely have been a standalone proposal), as we do often get regressions in physics bodies especially, so having a test project to validate changes for all backends would be great.
17:39 <reduz> oh yes, fully agree on part 1
17:40 <reduz> PouleyKetchoup: my plan is to dedicate myself more to fixing physics after 4.0 is out
17:40 <Akien> As for adding support for PhysX, it can be done as a module and we can decide to integrate it or not based on the result of the evaluation. Bullet brought lots of nice changes and features, but also hurdles and regressions, and I guess PhysX will be the same.
17:40 <reduz> there is a lot of work that needs to be done in the physics engines
17:42 <PouleyKetchoup> That sounds great! I like the idea to be able to plug any physics engine in gdnative for the long term. Would allow some developers to use Havok too.
17:42 <reduz> PouleyKetchoup: yes, the different engines have different strengths and weaknesses
17:42 <reduz> I want to aim at having a godot physics as default, which may not be the fastest or more featured but it would be tiny and do what most people needs
17:43 <reduz> then if you want more stuff, you can plug another physics engine

[Janders1800]

The license seems compatible with Godot.

https://gameworksdocs.nvidia.com/PhysX/4.0/documentation/PhysXGuide/Manual/License.html

[Callum17]

plug any physics engine in gdnative

This would be neat. Presumably a high level interface that pluggable physics modules can implement a subset of?

My personal interest is in deterministic physics solvers for multiplayer.
In particular nphysics / rapier

I know the current PhysX release (SDK 4.1) does not support soft bodies or gyroscopic forces - so there would definately be some regressions from bullet.

Believe the yet-to-be-release PhysX 5 SDK will bring back softbody support via a FEM solver.

[Darkinggq]

https://www.youtube.com/watch?v=t9KGC1otGc0 someone has already tested Bullet vs PhysX result impression performance shorter defeated Physx. :)

[Darkinggq]

see -> https://www.youtube.com/watch?v=XTE4B6yULR4

[FabricioMSantos]

The PhysX 5.1 SDK is now available as open source and also includes Flow for fluid, fire and smoke simulation, and Blast for destruction

https://developer.nvidia.com/blog/open-source-simulation-expands-with-nvidia-physx-5-release/

https://github.com/NVIDIA-Omniverse/PhysX

[Callum17]

The bit that concerns me:

finite element model-based soft body dynamics as well as liquid, cloth, and inflatable objects using position-based dynamics, optimized to run on GPUs

I think we would need to demonstrate that there is no vendor GPU lock going on. Frankly it is already concerning there is no viable CPU equivalent for FEM: if we are considering the CPU feature set only I am not sure physX 5 is adding much in terms of new capabilities. Nonethless any performance / accuracy comparisons vs the existing physics engine will be interesting.

[Calinou]

I think we would need to demonstrate that there is no vendor GPU lock going on.

PhysX's GPU acceleration seems barely used nowadays. I think any implementation will be CPU-only from now on, even if it means having a limited feature set. The issue is that physics tend to impact gameplay, so having them differ depending on the GPU used is a no-no for most games. GPU-based physics are also incompatible with headless servers, as these generally don't have any GPU to access.

[TheJackiMonster]

GPU-based physics are also incompatible with headless servers, as these generally don't have any GPU to access.

Not necessarily. If the GPU-based physics would be implemented using compute shaders with Vulkan, you could let it run on Lavapipe for example which is a valid Vulkan implementation on the CPU. It's not as performant. So I think for most cases this wouldn't make sense but it's not per definition "incompatible".

[Calinou]

Closing in favor of #7308, which is a more likely route for an official feature by now. PhysX can still be implemented as a community GDExtension if desired.

Physics tests projects for 2D and 3D have been added to godot-demo-projects a while ago:

• https://github.com/godotengine/godot-demo-projects/tree/master/2d/physics_tests
• https://github.com/godotengine/godot-demo-projects/tree/master/3d/physics_tests