Performance issues

[antzGames]

You should confirm the performance issues now that I published the test executables on my GitHub repo. Let me know if you cannot duplicate similar results.

The libGDX web performance is poor.

Here is a video of my performance test of Godot 4.5 vs. libGDX Jolt physics implementation: https://youtu.be/1vwJIjNa1ik

Here is the GitHub repo of the Godot and libGDX executables and HTML builds: https://github.com/antzGames/Jolt-libGDX-vs-Godot

Here is the PDF report that details out the test: https://github.com/antzGames/Jolt-libGDX-vs-Godot/blob/master/JoltPhysics-Godot-vs-libGDX.pdf

Godot is 1.71x faster than libGDX on Windows Desktop:

Godot is AT LEAST 2.70x faster than libGDX on HTML builds:

[yahel-ck]

I think it's worth checking if the performance bottle neck is the physics calculation or the rendering part.
From a quick look at source code the JoltScreen.updateModels method could be the cause of the bad performance.

Other than using instanced rendering, what I do in my own game to optimize physics+rendering is store each body's transform directly to a packed buffer that is copied as a whole each frame using glBufferData (My game still uses Bullet3 but the same idea could be implemented for Jolt).

It would be great if LibGDX provided a built-in system that does something like that.

To figure out what's the bottle neck here you could use some profiling tool to generate a flame graph and see which functions take up the most run-time. Or a simpler test would be to disable rendering the models completely and compare the performance with Godot for just the physics simulation.

[antzGames]

From a quick look at source code the JoltScreen.updateModels method could be the cause of the bad performance.

Other than using instanced rendering, what I do in my own game to optimize physics+rendering is store each body's transform directly to a packed buffer that is copied as a whole each frame using glBufferData (My game still uses Bullet3 but the same idea could be implemented for Jolt).

Godot was also not using MultiMeshInstance for the 3D models, which means it too is not using instancing.

[antzGames]

New developments. I found out the Godot only uses 4 threads on my system (one third of available threads on CPU). This means I was giving an unfair advantage to libGDX where it had 11 threads.

I will need to rerun the tests and build new runtimes for my tests.

[antzGames]

Here is the CPU load on all threads with no rendering of cubes (just physics). This is for proof that Godot is only using 4 threads.