Chaos 22 times slower than physx for rigid bodies?

I have tried the binary 4.26-Chaos build of the engine as well as a source build and in both instances Chaos is 22 times slower than physx for rigid body simulation. I came to this number by comparing the ms cost of physics during the exact same test in a 4.24 project, a 4.26-Chaos binary project, and a 4.26 source build with chaos added. The test consisted of 1600 chairs falling to the ground.

I have no idea what I am doing wrong or it is normal for a high performance physics engine to be 22 times slower than that which it is replacing simply because it is in beta. I want to experiment with chaos in my extremely physics heavy project but what was once running at 110 fps is now running at 5fps.

… its not optimized like physx so, yeah, until it’s 100% released (not in beta) it kinda is normal that it runs sub-par to something we have all used for nearly 10 years (perhaps longer).

Make sure your project settings are all correct though, if the chaos version comes with a pre-enabled sub-step, for instance, you can definitely expect to see such a performance reduction.

Also, make sure the chairs are instanced…
what .24 may do for you, .26 may not. (And more than likely the opposite is true too).

Another thing to check is also what the default iteration counts are between versions.
its possible that in an effort to provide a “better” simulation, they cranked the default iteration count way up compared to physx.

Btw, if I had to actually drop 1600 items and let them fall, I’d be writing a material shader for it, not relying on the CPU to do it. So what I’m saying, is that you also maybe expect way too much in terms of application.
That’s fine for a stress test and what not, but shouldn’t fly in a game…

Software that is explicitly designed to replace something for the purpose of improved performance and yet runs 22 times less performant in a stage as late as beta is not what I would have said is normal, thus my confusion.

Game thread was the bottleneck, draw calls were at 2ms.
I messed with physics iterations and performance is still extremely poor. I did confirm that substepping was not enabled on any project.

I said it was a test in my original post. I am asking about a repeatable performance discrepancy in controlled environment between two physics engines, not how to efficiently drop 1600 physics objects. I am not expecting anything out of Chaos that Physx isnt already doing. Physx already runs this test at an average of 7 ms. Chaos at 140ms. Chaos is a replacement for Physx, is it not?

Additionally, I do need a large amount of interactable physics objects that need to be CPU accessible with some of my current work outside of this test. I have a specific ms budget for physics and a specific need for that physics just like any developer and I have worked within those bounds using Physx. A shiny new physics engine that allows me to squeeze more into a given budget is of course, welcome.

So what would really help me is if you could tell me if you are getting the same relative results between the two physics engines on your machine.

1 Like

My test was limited to 1000 objects, back when .26 wasn’t released. With that, I didn’t notice any extreme difference as what you are reporting now. The performance was just about the same, give or take a stray ms.

Get a stat print out of the two tests so you can share them both here and possibly on a bug report.

Obviously something in the current version must have gone wrong…
could range between things, but I would check that the iterations and sub stepping isn’t hard coded in somewhere.

Chaos doesn’t support partial sleeping of islands yet (this is work in progress). It would be great if you could provide us with more information, this is super valuable to our team. Project/logs etc, as much as possible!

This contains Stat files and log files for the same stress test on both Physx and Chaos. I ran the test for 15 seconds. The same Map file was used in each test. Physx test was run on a 4.26 source build that I have modified slightly and the project is huge so I did not include the project for the Physx test (also it performs just like Physx). I did include the chaos project. It runs on the 4.26-Chaos binary build from the launcher.

I would LOVE to hear back from you about any conclusions. Chaos sounds like a dream on paper and I could benefit greatly in the future from the greater scalability and replication. I am obsessed with physical simulation in games and I would love to see Chaos do amazing things.

Also if I’m not witnessing the current potential of chaos, tell me how to witness it and what I’m doing wrong!
Cheers!

Also I’m on a i9-9900k

@VictorLerp

You forgot to tag him…

Thank you!

@VictorLerp

Could I ask if my experience with chaos is consistent at all with the experience internally at Epic?

I have tried porting a project from UE4 to UE5.0.3 and physics sims that run easily with no lag on five year old phones in UE4 are slow to the point of unusability on a 5950X; so I see no chance it’s even close to being plausibly usable in place of PhysX, even in the final release form shipping with UE5.

This really should have been a shift to modular physics because while there may be particular use cases that Chaos is beneficial for, it’s just not production ready. The lack of continued compatibility with PhysX, even through compilation flags now forces the choice between a maintained engine and usable physics.

Realistically, if you insist on using this inferior engine, you should pay for Havok to release something that has decent physics.

Or at the very least custom compile the engine without chaos, inspite of the process becoming increasingly harder.

In my testing, the latest (to 2 weeks ago) version of Chaos for ue4.27 is 75 times slower to run than physX.
Same scene, same objects. Just an insane MS count when running chaos.

And as you can see here, 0 engagment about the problem/situation.

End result?
Use CryEngine or just about any other engine…

Update for anyone curious. This particular performance issue comes from using the 2D physics feature, the degrees of freedom (Default Degrees of Freedom in the project’s physics settings page). If instead of full3D for degrees of freedom, you use one of the planes, as few as 20 rigid body boxes begins to degrade performance.

1 Like

Thank you for sharing.
Do you mean if someone wants the best results they should use “Full3D for degrees of freedom”?
Could you share some performance results as well?