Skip to content

Conversation

@ThierryBerger
Copy link
Contributor

Currently, bevy_rapier copies a lot of code from rapier, only to change a few signature functions for better glam compatibility.

In my opinion, wrapper types should be simpler: we should thrive to expose rapier types and limit code duplication:

Advantages of this approach:

  • less code duplication
    • less time to maintain bevy_rapier: as we encourage users to use rapier types, we don't need to copy rapier's functions.
    • less cognitive load: macros such as joint_conversion_methods! should only live in rapier.
  • better separation of concerns
    • Understanding rapier's functionalities should be oriented toward rapier's documentation, not bevy_rapier. The community would be able to better exchange on different features with a lower "wrapper overhead"

Ultimately, I think if should be possible to expose traits for glam (and nalgebra ?) capabilities, but that probably needs a more holistic approach with invasive (but I believe they could be made almost invisible) to rapier and rapier users.

Example to illustrate trait types for different library crates:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=5d57dccf5c175f862a20dbcdda149d58

@ThierryBerger ThierryBerger added D-Difficult Needs strong technical background, domain knowledge, or impacts are high, needs testing... P-Low A-Integration very bevy specific labels Jul 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Integration very bevy specific D-Difficult Needs strong technical background, domain knowledge, or impacts are high, needs testing... P-Low

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant