Jondolf

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!

Performance before (SAP) and after (BVH) for a scene with 40k static colliders.

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.

Avian's broad phase collision detection has finally been overhauled to use Bounding Volume Hierarchies from the OBVHS crate! Previously, basic sweep and prune was used.

This is a stress test with colliders in a grid moving randomly, rendering the resulting BVH. #bevy

PR: github.com/avianphysics...

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.

Initial support for joint motors has finally landed on Avian's main branch! #bevy #physics #simulation
github.com/avianphysics/avian/pull/913

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 ;)

Avian Physics 0.5 - Joona Aalto Bevy 0.18 support

I just released version 0.5 of Avian, an ECS-driven physics engine for @bevy.org.

This is the first update under our new release process, where we publish Bevy version updates separately from feature releases.

As always, an announcement post can be found here:
joonaa.dev/blog/11/avia...

A quick blog post on some recent changes and improvements to Avian's development, including new release and migration guide processes, a GitHub organization, and a dedicated Avian Dev Discord server. Also a brief update on plans for the 0.5 and 0.6 releases 😉
joonaa.dev/blog/10/evol...

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!

Avian finally has built-in move and slide, the movement and collision algorithm at the heart of kinematic character controllers! #bevy #gamedev #physics #kcc

PR: github.com/avianphysics...

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.

Avian is getting pretty big nowadays! To mark the start of a new release cycle, I spent some time improving our processes moving forward.

Notably, Avian now stores migration guides in-repo, similar to Bevy:
github.com/avianphysics...

Avian Physics 0.4 - Joona Aalto Massive performance improvements, and overhauled forces and joints

I just released version 0.4 of Avian, an ECS-driven physics engine for @bevy.org.

This is the biggest release yet, featuring 3x performance(!), overhauled forces and joints, voxel colliders, Bevy 0.17 support, and much more.

As always, release notes can be found here:
joonaa.dev/blog/09/avia...

Right now, the persistent nature of the implementation can make rollback networking trickier, so I kept an option to globally disable islands if they're causing problems (or if sleeping isn't needed). In the future, we might want to consider adding a non-persistent version as an alternative as well.

Avian's implementation persists islands across time steps, minimizing island building and splitting overhead. It is primarily based on @erincatto.bsky.social's excellent Simulation Islands article and Box2D.
box2d.org/posts/2023/1...

Previously, Avian only supported much simpler "per-body sleeping" that did not allow stacks of bodies or bodies connected by joints to fall asleep properly. This was always intended as temporary, but at least now we finally have the real thing :)

Persistent Simulation Islands by Jondolf · Pull Request #809 · Jondolf/avian Objective Closes #578. Sleeping and waking are crucial for reducing CPU overhead for large game worlds. Up until now, Avian has used basic per-body sleeping that only allows sleeping for dynamic bo...

Today, I finally merged simulation islands for Avian!

Islands are graph-like structures where bodies are connected via contacts or joints. They are used for sleeping and waking, which is crucial for reducing CPU overhead for large scenes with many dynamic bodies.

github.com/Jondolf/avia...