Performance - Time to optimise? about bevy_xpbd HOT 3 OPEN

This has been sitting here for a while now; apologies for not leaving a proper response sooner.

This is clearly a very important issue to address, and definitely one of the areas where bevy_xpbd is severely lacking in comparison to Rapier and many other physics engines.

I'm in the process of a major rework of the solver and a lot of the other internals (see #346, although it's slightly outdated at this point). It will hopefully be ready and released in roughly a couple of weeks. The new version only runs narrow phase collision detection just once per frame instead of once per substep, and is also more stable in general, which should improve performance for collision-heavy applications quite significantly (about 3-5x fps in some tests, but results may vary).

After that, I plan on opening a bunch of issues for further performance improvement work, as well as a tracking issue. Some big things include:

• Simulation islands (most likely persistent and parallel)
  • This would also fix sleeping, as the current per-body approach is not great
• Graph coloring for the solver to enable large-scale multi-threading on modern multi-core hardware
  • See Intel's paper: https://web.eecs.umich.edu/~msmelyan/papers/physsim_onmanycore_itj.pdf
• SIMD contact solving with wide types to solve multiple constraints at once
  • Requires wide types in Glam (I've been experimenting a bit with this)
• One-body constraints for interactions like dynamic-static contacts
• A better broad phase (most likely a dynamic Bounding Volume Hierarchy)
• Use par_iter in more systems in general (position integration, CCD, constraint preparation)
• Figure out a fix for #356

Simulation islands will probably be the first big improvement I plan on working on after the upcoming release, along with one-body contact constraints (which should be pretty trivial) and some smaller miscallaneous performance work. Other things like graph coloring and SIMD constraints might take longer, but I'm interested in trying to implement them as well.

In short, I acknowledge that the current performance frankly sucks for physics engine standards, and I really want to improve the engine in this regard. The new solver should hopefully address some collision performance issues, but there will still be a lot of follow-up work. I will lay this out in more detail in issues after the upcoming release.

from bevy_xpbd.

I was just coming here to write a similar issue. The move-marbles example is a fairly sluggish 30fps for me while moving them around.
I am researching libraries to implement something like this fluid simulation, which seems to have excellent performance with vanilla JS in a web browser. There are significantly more entities in that simulation too.

Thanks again for your amazing contribution!!!

I would definitely echo this, I am not trying to throw any shade on the developers here. This library seems really great already, just lacking in performance right now.
Thanks 🙏

from bevy_xpbd.

The new version only runs narrow phase collision detection just once per frame instead of once per substep

Amazing! great to see these small high-reward fixes. great work finding these!

Use par_iter in more systems in general (position integration, CCD, constraint preparation)

Sounds like good first-issues for contributors!

I have very high confidence in this project, given your priorities and roadmap. Well done!

from bevy_xpbd.