Jolt Physics just hit 10K GitHub stars! What started in 2014 as a CPU vs GPU ray casting experiment became a full physics engine in 2021. Seeing what you’re building with it is amazing. Thank you!
Thanks, yeah I fixed that now 😅 they got messed up when I updated some dependencies for the website and there was a small breaking change that I hadn't accounted for
I just released version 0.6 of Avian, an ECS-driven physics engine for @bevy.org. #physics #gamedev
v0.6 features move-and-slide, joint motors, and an overhauled broad phase using BVHs, resulting in massively reduced overhead for scenes with a large number of colliders.
joonaa.dev/blog/12/avia...
This is the game I've been working on the last four years. It is an incredibly ambitious project made by a small team. www.youtube.com/watch?v=7fax...
Congrats on the unveiling, looks super interesting! Very excited both for the game and for Box3D 😉
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 ;)
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...
