Jondolf

Jondolf

@jondolf.bsky.social

University student and software enthusiast, working on Avian Physics for #bevyengine. https://github.com/avianphysics/avian

322 followers39 following71 posts

Previously, Avian has supported f64 with a feature flag that changes almost everything to double-precision. This changes with my f64 overhaul. In short: Use f64 only for world-space values that degrade in precision far from the origin. This approach is inspired by Jolt. github.com/avianphysics...

github.comMinimal Use of `f64` for Large Worlds by Jondolf · Pull Request #1027 · avianphysics/avianObjective Related to #439. Avian supports both f32 and f64 by using type aliases like Scalar and Vector that choose the appropriate type based on the active feature configuration. When f64 is enabl...
View full thread

Here is a scene at 1e7 meters from the origin along the x-axis using single-precision. You can see the bodies form rows and get stuck in these quantized x-coordinates, as the floating-point step is about one meter at these distances. Behavior is very wonky!

Here is the same scene with double-precision. Even though the internals and APIs primarily use f32 values, there are no troubles at all!

Previously, Avian has supported f64 with a feature flag that changes almost everything to double-precision. This changes with my f64 overhaul. In short: Use f64 only for world-space values that degrade in precision far from the origin. This approach is inspired by Jolt. github.com/avianphysics...

github.comMinimal Use of `f64` for Large Worlds by Jondolf · Pull Request #1027 · avianphysics/avianObjective Related to #439. Avian supports both f32 and f64 by using type aliases like Scalar and Vector that choose the appropriate type based on the active feature configuration. When f64 is enabl...

Why, you may ask? 1. Our Scalar and Vector type alias spam in examples has been paining me since the start. People should learn to just use f32, Vec2, Vec3, Quat, etc. 2. Contributors regularly get CI errors due to f32/f64 type mismatches, causing a lot of gray hairs 3. Using f64 so widely is costly

4. Our upcoming SIMD optimizations are much more effective with single-precision numbers (hope to share more about my SIMD efforts soon!) 5. Peck, my upcoming collision detection library, only supports f32

You can also see how sweep-based CCD can reliably handle fast rotational movement (depending on the sweep mode), but has the downside of "time loss". However, enabling additional speculative CCD helps alleviate it.

The major improvement over our previous Bepu-style speculative CCD is that you no longer get ghost collisions when moving past objects at a high speed, as the default speculative distance is kept at a very small, fixed value.

One difference to Box2D is that we do still support "pure" speculative CCD as an opt-in feature, and also optionally support CCD between two fast-moving dynamic bodies. This allows scenarios like two projectiles reliably hitting each other midair, and bouncing off of each other.

Jondolf reposted

I’m happy to announce the release of a new open source 3D physics engine called Box3D. I’ve been working on this project for a few years now, but it represents over 20 years of experience writing physics engines for games. Read more here: box2d.org/posts/2026/0...

box2d.orgAnnouncing Box3DI’m happy to announce the release of Box3D, an open source 3D physics engine. It is now available on GitHub. Box3D repository You can think of Box3D as a fork of Box2D, extended with many features nee...

Jondolf reposted

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!

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...

View full thread

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!

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...

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.

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!

View full thread

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

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...

View full thread

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.

@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!

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.

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.

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.

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...

github.comPersistent Simulation Islands by Jondolf · Pull Request #809 · Jondolf/avianObjective 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...
View full thread

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.

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...

github.comPersistent Simulation Islands by Jondolf · Pull Request #809 · Jondolf/avianObjective 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...

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