Update to Bevy 0.17 and rapier 0.29 along with dependencies nalgebra, glam

[lukasfri]

Hey!

First time contributor. I don't quite know what I'm doing (no this is not in any way a vibecoded PR) but I was starting on a Bevy 0.17 project and needed bevy rapier for 0.17. I thought "how hard could it be" so I worked my way through updating all dependencies and making the necessary changes to get it to compile (including changing depreciations) and now everything seems to work fine (all tests pass). I fully understand if this migration needs changes, but it worked for me and in the meantime it works as a stopgap for anyone who wants a commit they can pin to.

Best wishes

[Guelakais]

I see two options here if you want to do it right: split your commits further or squash everything together. On the one hand, your commits are too large. You are combining commits that only deal with documentation (the markdown files) with those that deal with the actual features (the Cargo.toml and *.rs files). This makes your commits very confusing. In addition, it is bad style to tinker with the same file multiple times and create a separate commit each time. Commits and pull requests should always be as small as possible to remain manageable. Here, you have changed the same file (changelog.md) with multiple commits. That is not necessary. Put all commits that deal with this file together. That makes the whole thing much cleaner.

Even though my response is very detailed, I think the pull request is good overall. Keep up the good work!

[lukasfri]

Hey! Yeah, the PR needs some work before going to the tree, I mostly just wanted to check if there was any interest in merging if I fixed it up, and I needed a quick fix for myself. It seemed rude to just barge in and make a large amount of changes which is why I wanted to gauge interest before sorting it, but if it's welcome I'll clean up the commits.

[mnmaita]

Tested this branch in my project and so far so good! I'm leaving a few comments for you to review. Thanks a lot for creating this PR.

[lukasfri]

Implemented changes as requested, squashed the commits to be more understandable. First one is still big, but I have no real way of splitting it that I know of bar manually going from the beginning, sorry.

Remaining question is if I should rename MassModifiedEvent, CollisionEvent and ContactForceEvent to end in Message since they are no longer Events. I don't know the depreciation policy in this crate, but creating a type alias with a depreciation notice shouldn't be a problem as far as I'm aware unless there are wishes not to change.

[lukasfri]

I made the change as it is my personal preference. In the change I've added pub use aliases (with depreciation notices) to make possible a future removal. If this is not preferred, I'll simply revert later but since I was in the editor I thought I might as well.

[mnmaita]

Regarding these version suggestions I'm pretty sure library consumers will get the latest versions of the dependencies if they cargo update so I wouldn't worry too much. But for correctness some of these versions could be stated up to the minor version (skipping the patch), like 0.30 for example. I'd defer this to the library maintainers honestly. cc @ThierryBerger @sebcrozet

[Guelakais]

Regarding these version suggestions I'm pretty sure library consumers will get the latest versions of the dependencies if they cargo update so I wouldn't worry too much. But for correctness some of these versions could be stated up to the minor version (skipping the patch), like 0.30 for example. I'd defer this to the library maintainers honestly. cc @ThierryBerger @sebcrozet

You're right. My suggestions shouldn't prevent the merge. I've approved it now. In my experience, it's best to keep the Bevy dependency as up to date as possible, as Bevy version changes have introduced a lot of major API changes in the past.

[ThierryBerger]

Thanks! it looks good, testbed examples are broken so I offered a fix at lukasfri#1 ; once CI is green it may be good to go :) ; I see wasm and wayland issues.

[lukasfri]

@ThierryBerger Thanks! Need workflow approval to run CI

[mnmaita]

Adding libwayland-dev libxkbcommon-dev to

bevy_rapier/.github/workflows/main.yml

Line 34 in 7258dc4

- run: sudo apt update && sudo apt-get install pkg-config libx11-dev libasound2-dev libudev-dev

and

bevy_rapier/.github/workflows/main.yml

Line 49 in 7258dc4

- run: sudo apt update && sudo apt-get install pkg-config libx11-dev libasound2-dev libudev-dev

should fix the CI issues. I think Wayland was made default in 0.17 so the runner needs a new dependency to support it.

[jackbackes]

So close! Just need someone to kick the CI! :-)

[tylersaunders]

[Apologies if this is considered slightly off topic.]

I've tried integrating this pull in my own project while traversing the bevy 0.17 upgrade, and I've encountered an issue I can't quite pin-point the source of. (I'm using bevy_rapier2d for reference)

ColliderDisabled seems to no longer have any effect on the active state of a collider with this pull, where as previously on 0.31.0 this would disable collision processing for the collider.

I don't see anything in this pull that would have caused it, but perhaps more a bevy 0.17 behavior?

The migration guide seems to suggest its just a rename for RemovedComponents, but figured I'd just mention it in passing while I was working on my own migration.

[lukasfri]

@mnmaita CI start please ❤️

[lukasfri]

@tylersaunders No issue at all, seems reasonably on topic. I took a look myself and I can't find something either. Is it possible you could create a regression test that showcases the issue?

[mnmaita]

@lukasfri I don't have such superpowers 😆 but anyway just wanted to point out that I think you've missed adding the wayland deps in L49 of main.yml. Please also double check if there are any other spots in the scripts where linux related deps are installed in case I missed some. After that I assume @ThierryBerger or @sebcrozet would be able to help triggering workflows again.

[lukasfri]

@mnmaita Ah, sorry! Yeah I don't know how I missed that, was a bit too quick...

[ThierryBerger]

Thanks for updating, the wasm issue comes from getrandom requiring a RUSTFLAG and the feature wasm_js, more info at https://docs.rs/getrandom/latest/getrandom/#webassembly-support

[stillonearth]

I've tested this on my URDF simulation that worked on 0.16 and now get bouncing behavior for urdf-imported robot. I've checked the colliders and they look fine. What might be the source of a regression? The body I'm simulating should behave as rigid, and I turned off all motors.

bounce.mp4

[Jondolf]

This PR changes all the events/messages to have the Message suffix, but I'll just note that it's generally not considered good practice. See Cart's message on event and message naming conventions. Cart even explicitly calls out the collision event example, that you should call it Collision, not CollisionMessage.

Additionally, Cart suggests that:

If the specific context of a message requires the "event" terminology for clarity, then the XEvent suffix is ok. Ex: RawWinitWindowEvent

I think some of the types here might qualify under this. For example, we cannot call the ContactForceEvent just ContactForce, as that would be very confusing. In Rapier, this feature is fundamentally called a "contact force event" (link), and the fact that it is sent as a message doesn't change that. So it could potentially be left as ContactForceEvent.

This is similar to the philosophy I went for in Avian (though my event names are different). I still call collision events "collision events" and not "collision messages", even though they can also be written as messages. I had some more rationale in the Avian 0.4 release notes here:

The term “collision event” or “contact event” is extremely common across a variety of engines. With Bevy’s recent naming changes, it begs the question of whether we should abandon this standard and start calling the Message version a “collision message”.

From my point of view, the answer is no. The difference is subtle, but instead of saying that the type is a message, we say that it is written as a message. The defining factor of the type is that it is fundamentally a “collision event”, even if it can be sent as a message. See cart’s message on general naming guidelines for messages and events.

Anyway, the decision is up to Rapier people, I just wanted to point out Cart's suggested naming conventions in case people hadn't seen them :)

[notdanilo]

I just tested bevy_rapier2d = { git = "https://github.com/lukasfri/bevy_rapier", rev = "a5c82f08c86f9fd44430081e7d6ea1a5bb296e8b" }

and it's working well for Windows, Web and Android 👍🏼

[Deniskore]

A couple of days ago, I started my project using Bevy and got stuck on the fact that rapier does not support the latest version of Bevy.

What needs to be done to merge it and release a new version? I can allocate some time to help if needed.

I think it makes sense to update Rapier to 0.30.1

[lukasfri]

There appears to exist a few issues that need to be fixed before merging:

• @stillonearth regression
• wasm issue in CI needs fixing.
• @tylersaunders issue with ColliderDisabled needs to be investigated.

I don't have the bandwidth right now to continue doing taking care of those issues myself, but I'll obviously merge any fixes into my branch. My interest in upgrading were limited to a side project I was doing to get it working for myself temporarily. However I've got no problem pressing CI buttons etc.

If you @Deniskore want to tackle the above you're more than welcome.

[notdanilo]

@lukasfri this possibly fixes the wasm issue

.cargo/config.toml

[target.wasm32-unknown-unknown]
rustflags = ["--cfg", "getrandom_backend=\"wasm_js\""]

[mnmaita]

@lukasfri this possibly fixes the wasm issue

.cargo/config.toml

[target.wasm32-unknown-unknown]
rustflags = ["--cfg", "getrandom_backend=\"wasm_js\""]

Plus enabling the js feature for getrandom in Cargo.toml (if not done already):

[target.'cfg(all(target_family = "wasm", any(target_os = "unknown", target_os = "none")))'.dependencies]
getrandom = { version = "0.3", features = ["wasm_js"] }
getrandom_02 = { version = "0.2", features = ["js"], package = "getrandom" }

The getrandom_02 line won't be necessary if 0.2 is not in the dependency tree. You should be able to check that by doing cargo tree | grep getrandom or something like that.

[mnmaita]

There are some doc failures too that should be easy to fix (TriangleList has a different path now and Visibility might need to be imported in picking_backend/mod.rs).

[Deniskore]

Guys, can someone ask sebcrozet to check my PR in the rapier repository? The changes are minimal, and we'll finally be able to merge my fix for bevy_rapier 👀

Most plugins have migrated to version 0.17.2

[Guelakais]

Guys, can someone ask sebcrozet to check my PR in the rapier repository? The changes are minimal, and we'll finally be able to merge my fix for bevy_rapier 👀

Most plugins have migrated to version 0.17.2

please post a link of your pr.

[sebcrozet]

@Deniskore If the PR you are mentioning is dimforge/rapier#894, I will check it out tomorrow.

[Deniskore]

Guys, can someone ask sebcrozet to check my PR in the rapier repository? The changes are minimal, and we'll finally be able to merge my fix for bevy_rapier 👀
Most plugins have migrated to version 0.17.2

please post a link of your pr.

@Guelakais You can see references to both PRs above my message.
@Guelakais @Jondolf Could you also review the PR for the update to 0.17.2? 👀

Anyway, here are the links:
Update to 0.17.2
Bevy rapier fix

@sebcrozet Yes! The link is correct. I am ready to fix any issues, if you provide the necessary feedback.

[lukasfri]

Hey! My apologizes for not seeing this through. My last last few weeks have been very hectic so I haven't had any additional time available. Great job @Deniskore , thanks for finishing the work!