A Rapier3D branch Or the code with both "avian" and "rapier3d" feature

[xx1adfasd]

I can be of help for the rapier3d code if the suggestion is approved. By having both code, the user can easily adopt which one they want to code with, and this makes the project unbiased on the physic engine choice.

The code will be very alike, and lines related to avian3d replaced with rapier3d ones. And I think we can refer to what tnua project did, as it have features for both rapier3d and avian3d.

By the way, I just checked the history and I saw that the case to switch from rapier to avian is because of the camera jitter problem. But recently I just switched from avian to rapier for the same reason, the camera jitter problem! Looks like sometimes the code of bevy, avian and rapier all changes and the jitter problem can happen unexpected. It's a good reason to have a template to have both engine included.

[janhohenheim]

Thanks for the offer! I think this is one place where I want to be opinionated. I would currently recommend Avian over Rapier to most people due to the much better ergonomics. The major blocker there were performance issues and the most egregious case was fixed recently. There are still open performance optimizations, but Avian is pretty good right now compared to bevy_rapier, which suffers from quite a bit of overhead compared to pure Rapier.
The other blocker is missing features, but most of these are specialized enough that I think most users will be alright without them. If not, they can easily switch to Rapier themselves.

As such, I currently want to keep Foxtrot Avian-only. We could however point out that bevy_rapier exists in the readme and tell users that they should switch if they run into the issues linked above.

[xx1adfasd]

I understand. It's fair. And by now I realized that different developers will encounter different situations, and it's so hard to adopt all the physic engines.

By the way, just as a remind for people who want to see the difference, most common used simple physics code are the same for both avian and rapier. But I do see that as people are moving to avian/xpbd, developers are become fewer for rapier and there are some codes more easy to write in avian. (I'll list some that I encountered: pausing time, enum collision layer )

For the "pretty good right now" link, I'm sorry I can't use discord so... But I do know that dependencies that foxtrot used like oxidized_navigation,tnua,blenvy are all using both rapier and avian as well, and I learned them all by learning foxtrot, so I some how become an unbiased guy too... There's some more code-chain or develop-chain here might make people stay in using a certain engine for quite a while.

So as a consequence I want to make a fork, called Foxtrot-rapier, if you don't mind. I just want to create a counterpart code just as a reference, keeping up-to-date with foxtrot with only physic engine changed.

https://github.com/xx1adfasd/foxtrot-rapier

Thanks again for the great project!

[janhohenheim]

@xx1adfasd that's cool! Mind if I link the fork in the readme so people know where to go if they want to use rapier?
Also, I will soon do some fairly massive changes in #327. You may want to re-create the fork afterwards instead of pulling in the changes as I imagine you will get a lot of merge conflicts.

[xx1adfasd]

@xx1adfasd that's cool! Mind if I link the fork in the readme so people know where to go if they want to use rapier? Also, I will soon do some fairly massive changes in #327. You may want to re-create the fork afterwards instead of pulling in the changes as I imagine you will get a lot of merge conflicts.

Of course I'm happy to be mentioned in README. As attentions was paid to the rapier project, I then have to maintain it, which is a good practice.
And I will be glad to follow your steps to re-create fork/ merge all the files, as a practice.