Rebrand Bevy XPBD and Switch Solvers

[Jondolf]

I am making this as an early notice of major upcoming changes and to explain their rationale. There are important issues that need to be addressed, and I want to be as transparent as possible.

Within the next couple of months, we will attempt to transition away from Extended Position-Based Dynamics (XPBD) and rebrand bevy_xpbd. This involves a partial rewrite of the internals and a rename for the crate.

There is a lot of text here, so if you want to skip to how this might affect you, feel free to skip ahead to the Questions and Conclusion sections. For full context, however, I recommend reading on.

Why?

bevy_xpbd started as a small project with the idea of trying to build an ECS-first physics engine for Bevy using this shiny new simulation method called Extended Position-Based Dynamics. XPBD looked very promising and intriguing, providing great stability through an innovative substepping scheme and expressive position-based constraints.

However, as I've come to learn over the crate's development, using XPBD comes with several issues. Perhaps the most serious one is that XPBD is technically patented by NVIDIA.

There is no prior record of NVIDIA coming after projects using XPBD, and there are several existing open source implementations of it, but the patent still exists. This is a potential risk to me as the author of bevy_xpbd, people distributing projects using it, and to the ecosystem as a whole. bevy_xpbd can not be officially adopted by Bevy as long as it uses XPBD, nor can it be recommended by its maintainers. For the benefit of everyone involved, we must transition away from XPBD.

As an initial action, I have added a warning about this in the README that links to this issue. For projects using bevy_xpbd right now, there should be no reason to panic, but it is important to be aware of the legal concerns. While this is very unlikely to cause issues for smaller projects in practice, it is technically up to the user to have the rights to distribute the library in their works.

Aside from potential patenting issues, XPBD also has some problems on the simulation side of things.

• Overlap is solved by pushing bodies apart at a position-level. This makes cases where bodies are constantly overlapping (like squished in a confined box) very energetic and potentially explosive.
• Position-based constraints can often have high-frequency oscillation where bodies are always slightly moving back-and-forth. Looking up close, this can sometimes be noticeable. XPBD rarely (if ever) reaches a completely stable and relaxed state without sleeping.
• Friction is typically not quite as robust as it is with impulse-based methods. There are several ways of handling it, some better than others, but it can still have some issues.
• With the Gauss-Seidel approach to XPBD, the order in which constraints are solved can have quite a large impact on the end result.
• Some features seem more challenging to implement, and there are fewer learning resources and references for the usage of XPBD in game physics.

Overall, XPBD does not seem like the right choice for Bevy's physics. Especially the legal implications can be considered to be a critical blocker for potential official adoption, and not worth the risks.

Why Now?

When I began working on bevy_xpbd, I was not yet aware of the patent. It was a small hobby project I was making for fun, and I never expected it to gain the traction it has.

Now, bevy_xpbd has become one of the most popular crates in the ecosystem, and is being used in more and more projects. It is becoming increasingly important to address the potential issues before serious projects using bevy_xpbd are released. This is a concern shared between me and the maintainers of Bevy itself.

In the early days of the crate, the XPBD part also played a larger role and was one of the core selling points. Nowadays, the focus has shifted more towards building a physics engine that specifically suits Bevy's needs and provides native ECS-like APIs. As such, the name bevy_xpbd is no longer as representative of the goals of the project, even though XPBD is still used internally.

The New Solver

We will switch XPBD to an impulse-based approach, the standard in the domain of physics simulation. The details are unclear as of now, but the most likely contender is what Erin Catto (the author of the Box2D physics engine) calls TGS Soft, or Temporal Gauss-Seidel Soft. It is an impulse-based solver with an XPBD-like substepping scheme and soft constraints, which add spring-like damping to constraint responses. It is also extremely close to the solver that Rapier recently switched to.

Does this mean worse stability in comparison to XPBD? No, it's most likely the opposite! Erin Catto compared solvers in his Solver2D project, and found that TGS Soft surpasses almost every other solver in nearly all tests, even beating XPBD in tasks it is supposed to be great at. His XPBD implementation did have some flaws, like incorrectly handled friction, but TGS Soft should definitely be a great replacement, and Rapier also saw substantial improvements with a similar approach.

I started initial experimentation with the solver a few weeks ago, and will continue to do so. I unfortunately have my matriculation exams this month, but after them, I will start seriously working on the solver rework.

Another option to consider is to try to make the solver easily swappable via plugins. This way, an XPBD solver could still be provided by a third party crate (with the appropriate warnings). This is a secondary goal however.

The Rebrand

As we will no longer be using XPBD, we will need to rename and rebrand the crate.

I have not decided on a name yet (edit: it will most likely be bevy_dynamics), but it will be something that is independent of the solver or other implementation details in order to avoid similar situations in the future. Feel free to leave suggestions!

One unfortunate side effect of this is that it will also impact third party crates that extend bevy_xpbd, like bevy-tnua-xpbd2d/bevy-tnua-xpbd3d by @idanarye, bevy_xpbd_interp by @rubengrim, and bevy_xpbd_3d_parenting by @ActuallyHappening. Once we rebrand bevy_xpbd, third party crates like these should also be renamed if they wish to support the new crate. I sincerely apologize for any trouble this causes.

How It Will Happen

I will briefly cover the steps that I plan on taking to make this solver switch and rebrand happen.

1. Issue a warning in advance, and explain the plan. This is the purpose of this issue.
2. Replace XPBD with another approach, most likely TGS Soft. This will hopefully happen by the end of April if all goes well, but I do not have a precise estimate.
   • This will require changes to the integrator, a rework of the solver and all constraints, and modifications to scheduling.
   • I will try my best to retain all existing functionality without regressions.
   • I will also make more examples to directly compare XPBD to the new approach.
3. Update the documentation and README to reflect the changes, leaving a note about the rebrand for at least the first release of the new crate.
4. Release a final version of bevy_xpbd, with a deprecation warning.
5. Rename the repository and publish the first version of the new crate.
6. Announce the rebrand everywhere: On Reddit, the Bevy Discord, my blog, and so on.

The rebrand is bound to cause confusion, which is why I am making this issue so far in advance. There will be a time period where people will continue to look for bevy_xpbd even after the rename, and we will just need to inform them of the rebrand.

I will also try my best to periodically share my progress in the Bevy Discord, both to promote the changes and to show where we're at. Feel free to ask me (@jondolfdev) anything there.

---

Questions

What does this mean for projects that use bevy_xpbd?

XPBD is patented by NVIDIA. There should be no reason to panic, but it is important to be aware of it. While it is very unlikely to cause issues for smaller projects in practice, it is technically up to the user to have the rights to distribute the library in their works. Just know that there are plans to address the issue in the coming months, so there should be no need to stop using bevy_xpbd for projects that are in development.

Once the rebrand happens, if all goes well, you will simply need to change the name of the crate. All existing functionality should remain the same. For any other changes that may happen, there will be a migration guide.

What does this mean for crates that extend bevy_xpbd?

bevy_xpbd will be renamed. Authors of crates with xpbd as part of the name will need to rename their projects if they wish to support the new crate. Similarly, xpbd feature flags should be changed to reflect the new name.

The structure of bevy_xpbd is also likely to change a bit, which might require minor modifications to some projects. There will be a migration guide to ease the migration.

What does this mean for the engine overall?

This should not be a downgrade, but rather the opposite! I am hopeful that the new solver will be better than XPBD, and it will make some new features and improvements easier to implement.

Transitioning away from XPBD will also remove one of the major blockers from having the physics engine as a potential option for an official Bevy physics integration some day in the future. Of course, there are still other blockers, like performance, some missing features, and a reliance on Parry, but it is a big step forward and should also make it easier to address some of the other issues.

Conclusion

To summarize: XPBD is patented by NVIDIA, and has characteristics that prevent it from being the best choice for physics in Bevy. Over the coming months, we will transition away from XPBD and rename the crate.

Projects in development may continue using bevy_xpbd in the meanwhile. Just be aware of the potential risks with distributing it, as it is technically up to the user to have the rights to do so.

This is an unfortunate situation, but something that is very important to address for the sake of everyone involved. Feel free to ask any questions here or on Discord, and thank you for your understanding.

[unwx]

Is there any plan to use GPU for the physics engine? As I understand it, XPBD currently operates solely on the CPU, correct? Theoretically, this could significantly improve performance.

If so, at what stage of development is this? Looking at Bevy, they started using wgpu from the early stages of development. Would it be a good idea to take a similar step: a new solver (for example, TGS Soft) but focused on the GPU?

Bevy was built on wgpu from the very beginning, which meant most of the hard work of supporting WebGPU was already done

[entropylost]

@unwx using the GPU is most likely not worth it; unless the shape of the problem is very regular, aka colliding a bunch of spheres or something, it'd be really hard to make the GPU happy about the branching for colliding all the different shapes. Apparently, PhysX does so anyways, but I feel like there wouldn't be much benefit in any case. A system for simulating particle effects on the GPU may be valuable though, but that's beyond the scope of this crate.

[Jondolf]

Hi! It's been a while, so here's a quick update on the state of things.

XPBD Patent

A while ago, we sent an email to NVIDIA asking about the legality of using XPBD to create an open source, MIT-licensed, physics simulation library. We actually got a response from Miles Macklin, one of the inventors of XPBD, who is also listed in the XPBD patent.

… I don't believe there is any restriction here – you can already find many open source and commercial examples of XPBD implementations online. …

The wording is a bit vague, but it is encouraging that it seems like using XPBD should be fine. Of course the patent is assigned to NVIDIA itself however, so I believe they technically hold the power (I am not a lawyer).

Either way, I'd like to transition away from XPBD even for reasons unrelated to the patent. The upcoming release still uses it for joints, because changing them to be impulse-based would delay things unreasonably, but the rest of the engine has already transitioned away from XPBD completely. In the future, I might also rework joints so that they don't use XPBD.

The Rebrand

The new name of Bevy XPBD will very likely be Avian Physics, or just Avian for short 🪶

My criteria for the ideal name were:

• Related to physics or motion in some way (avian: relates to birds and flight).
• Not tied to a specific physics implementation like bevy_xpbd was.
• Unique and has its own brand identity. Like Bepu, Jolt, Havok, and so on!
• Relatively short, ideally 4-6 characters.
• Easy to pronounce and spell.
• SEO-friendly and googleable.
• Ideally has some kind of connection to Bevy, and relates to birds or flight 🐦
• …but not strictly tied to it. Maybe one day we find a way to use the engine without the Bevy core and the ECS?
• I just personally like the name and how it looks.

I had dozens (or even hundreds) of name ideas, most of which were already taken or only satisfied a few of these criteria. A bunch of community members also helped with great suggestions, thanks for all of them :)

After a couple of months(!) trying to come up with a name, I landed on Avian, because it fits basically all of these criteria perfectly. It's nice and short, not reserved by any existing projects, and overall just feels like a pretty natural name for a Bevy physics engine.

I have already designed a logo, with the help of other community members:

Of course, we could always spend more time bikeshedding names, but I'm personally very content with Avian.

Crate Naming

The new crates will be called avian2d and avian3d. I ditched the bevy_ prefix, because:

• Again, maybe one day we find a way to use the engine without the Bevy core and the ECS?
• A name like bevy_avian would sort of imply that it is a Bevy integration for an avian crate, not the core crate itself. Things could get confusing if someone else then made an avian crate.
• 3rd party crate names don't have to be as long, and we could even have official sub-crates like avian_collision, avian_spatial, and avian_math (although in practice, these might just have their own names)
• Several people stated they prefer names without the prefix. This is also not uncommon: big-brain, big_space, lightyear, leafwing-input-manager (and other Leafwing crates) are all Bevy plugins.

The repository and documentation will of course continue to mention that it is a crate for Bevy.

Release Strategy

My plans for the next release(s) are the following:

1. Release Bevy XPBD 0.5 once Bevy 0.14 releases.
   • For the most part, this is just an update for the new Bevy version to help with migration, with no large new features or breaking changes.
   • This is already on the bevy-0.14 branch, but note that it currently depends on some forks and is not final.
2. Release Avian 0.1 once Bevy 0.14 releases.
   • This has the entire rework with all the new features and changes.
   • There is already a WIP avian branch. I am in the process of making PRs targeting this branch to add all of my changes. Once everything is ready, I will merge avian to main, and the rebrand will be complete!

I recommend that third party crates for bevy_xpbd also rebrand accordingly to the avian naming once the crate is released.

Coming in Avian 0.1

The new crate has lots of cool new stuff! This includes:

• A completely rewritten contact solver using impulse-based TGS Soft instead of XPBD.
  • Performance and stability are significantly better for collision-heavy applications.
  • A similar solver is used by Box2D V3, Bepu, and nowadays Rapier.
  • I hope to cover this in more detail in a future blog post.
• A rewritten narrow phase.
  • Runs once per frame instead of once per substep. Results in huge performance gains for apps with several substeps.
  • Less allocations, overall better performance.
  • Several bugs related to collision events fixed, like #224.
  • More capable and cleaner, logic refactored to be a system parameter.
• Speculative collision, a cheap but relatively robust form of Continuous Collision Detection (CCD).
  • Enabled for all bodies by default, eliminating effectively all tunneling with minimal performance impact. Any remaining overlap is due to contact softness.
  • Similar to Bepu and Box2D V3.
• Opt-in sweep-based Continuous Collision Detection (CCD).
  • More expensive than speculative collision, but can be used as an additional safety net to prevent all tunneling.
  • Non-exclusive: can be used together with speculative collision.
  • Doesn't use substepping. This is cheaper, but can lead to "time loss", and doesn't handle secondary collisions properly.
• Joint improvements
  • Improved stability. Several joints are less stretchy and have less high-frequency jitter.
  • Spherical joint limits are more capable. Elliptic cones and pyramidal limits!
  • (Hopefully) local frames, allowing you to specify reference orientations in addition to the local anchors.
• A reworked module structure, with a clearer seperation of concerns.
  • See #370.

And much more! There are still a few more things I need to work on, but everything should hopefully be ready in time for Bevy 0.14.

This is a packed release, and I still have a ton of further work planned. I haven't had as much time for general maintenance and responding to issues during this rework (sorry about that!) but I'll try to spend some more time on that after the release, along with opening lots of new issues.

As usual, I plan on writing up a migration guide and a blog post for the release when I have time. Stay tuned for more updates :)