Hah, yeah gizmos are really the main bottleneck here. Beyond 10k colliders I have to disable debug rendering or it just kinda tanks performance in this scene. At one point I tried to implement some custom line drawing stuff, but I didn't spend too much time on that yet

Note that spatial queries such as ray casts and shape casts don't use this yet. Instead, they use a BVH from Parry, which we update and manage quite inefficiently. Reusing the broad phase BVH for spatial queries is next on my list!

Huge thanks to DGriffin91 for implementing incremental leaf insertion and removal, partial rebuilds, improved traversal, and much more for OBVHS to make it suitable for physics <3

Go show him and OBVHS some love!
github.com/DGriffin91/o...

Note that this doesn't necessarily mean that SAP is inherently slow, our implementation was just extremely basic 😅 though I do think that BVHs are the better choice for a general game physics engine. Plus, I designed it so that you can swap it out with your own broad phase algorithm if you'd like!

The performance impact is massive for scenes with a large number of colliders. Previously, 40k static colliders in 2D could easily cost nearly 10 ms of the frame budget, while it is now under 1 ms. Dynamic scenes also perform a lot better than before.

Thanks again to pierre-l for such great work on implementing a large and complex feature like this!

Note that the implementation may end up being rewritten if/when we finally switch our XPBD joint solver to something else. But joint motors have been a common request, and the API will likely remain the same even if we change the internals, so I decided that it's worth shipping them already :)

pierre-l on GitHub implemented them in #913 for revolute and prismatic joints, supporting both velocity control and position control. Three motor models are included: ⁨ForceBased, ⁨AccelerationBased, and ⁨SpringDamper.

Spherical joints don't have motors yet, but will be supported in the future.

A separate Avian 0.6 feature release with new functionality and improvements will be published when it is ready, hopefully in time for Bevy Jam #7 🤞 There are some cool things coming in that one ;)

For reference, Rapier's KCC only considers one plane at a time (but does more iterations) and doesn't do depenetration. It performs fine with basic sliding, but *really* struggles with even mildly complicated geometry. Very jittery in multi-plane cases, and a whole 6 ms against the end of the tube 😬

You can also run this in parallel for many character controllers, so I would expect you to be able to have hundreds or thousands of characters moving around simultaneously in most scenes. I haven't tested this yet though! Would be a cool benchmark.

Depends on geometry. In this scene:

no collisions: ~5 us
sliding along two flat surfaces: 40-50 us
the side of the flight mask's tube: 400-500 us
the end of the flight mask's tube: 600-800 us

Most collision geometry in games should be fairly low-detail and cheap, unlike the flight mask here.

@janhohenheim.bsky.social and I have been cooking this up over the past couple of weeks, but many others have also taken part. Special thanks to UB for a lot of early experimentation, IQuick143 and unpairedbracket for math help, and vero and several others for testing and feedback <3 you all rock!

Note that this currently just includes a MoveAndSlide system parameter and related utilities. More user-friendly ECS-driven APIs, character controller features, and examples will come later.

Our implementation comes with a robust (somewhat novel?) multi-plane velocity solver and depenetration, to minimize cases where you get stuck or encounter jitteriness. Preliminary results in testbeds and @janhohenheim.bsky.social's Source-inspired KCC bevy_ahoy are looking great!

I have some more ideas for improving our processes, namely adding a contribution guide, collecting some useful learning reasources for physics simulation, and also switching to a more frequent release cadence with smaller, more incremental releases, but I'll have to chew on those some more.

After seeing the old Avian URL for so long, it does look a bit weird now 😅 But I think it's good long-term, just a matter of getting used to it :)

Wait... Was that a different URL I see? Yup! The Avian repository is now under a new Avian Physics organization instead of my personal profile. This is more professional, and more importantly, it lets us give people triage permissions to label or close issues and PRs, among other things.

This has several major benefits: main branch users have migration guides available, the guides are kept up-to-date (and written by the people who made the changes), and I don't have to crunch at the end of each cycle to gather them from scattered PRs and spend ages fixing and updating them.