Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reflect and register Collider type #404

Open
timothee-haudebourg opened this issue Jul 16, 2023 · 4 comments
Open

Reflect and register Collider type #404

timothee-haudebourg opened this issue Jul 16, 2023 · 4 comments
Labels
A-Integration very bevy specific D-Difficult Needs strong technical background, domain knowledge, or impacts are high, needs testing... P-High arbitrary important item S-not-started Work has not started

Comments

@timothee-haudebourg
Copy link

timothee-haudebourg commented Jul 16, 2023

Hi, I'm blocked because the Collider type is not registered to the app, and cannot be manually registered because it lacks the required traits implementations. I guess it is related to this TODO:

#[derive(Component, Clone)] // TODO: Reflect

I suppose this is not the only type that requires reflection. Is there any work in progress to add those? If not I may write a PR.

@timothee-haudebourg timothee-haudebourg changed the title Reflect and register types Reflect and register Collider type Jul 16, 2023
@Aceeri
Copy link
Contributor

Aceeri commented Jul 25, 2023

This currently requires some changes on bevy_reflect side as Compound is a self-referential type, I would suggest using https://github.com/devildahu/bevy_mod_component_mirror for now, but know that it will be a subset of the available collider types.

@Luminoth
Copy link

it looks like the linked PR has been merged, is the door opened now to impl Reflect on Collider? The space editor project has a requirement on that for Components.

@Vrixyz Vrixyz added D-Difficult Needs strong technical background, domain knowledge, or impacts are high, needs testing... P-High arbitrary important item S-not-started Work has not started A-Integration very bevy specific P-Medium and removed P-High arbitrary important item P-Medium labels May 23, 2024
@janhohenheim
Copy link
Contributor

Semi-relevant issue: dimforge/rapier#467

@Zeenobit
Copy link

Zeenobit commented Jul 23, 2024

The HEAD revision of moonshine-save now supports "component mappers" to solve this issue as a workaround.

It's a similar idea to component mirror, but baked into the save pipeline:

app.register_type::<SerializedCollider>()
  .add_systems(
      PreUpdate,
      (
          save_default()
              .map_component(serialize_collider)
              .into_file("example.ron"),
          load_from_file_with_mapper(
              "example.ron",
              SceneMapper::default().map(deserialize_collider),
          ),
      ),
  )

Where serialize_collider and deserialize_collider are defined as:

#[derive(Component, Reflect)]
#[reflect(Component)]
enum SerializedCollider {
    Ball(f32),
    // ...
}

fn serialize_collider(collider: &Collider) -> SerializedCollider {
    if let Some(ball) = collider.as_ball() {
        SerializedCollider::Ball(ball.radius())
    } else {
        todo!()
    }
}

fn deserialize_collider(serialized: &SerializedCollider) -> Collider {
    match serialized {
        SerializedCollider::Ball(radius) => Collider::ball(*radius),
        _ => todo!(),
    }
}

I'm curious to know if:

  1. Can every collider be serialized indirectly like this? If not, what subset of it could be?
  2. Are there any other types in bevy_rapier that suffer from the same issue?

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-High arbitrary important item S-not-started Work has not started
Projects
None yet
Development

No branches or pull requests

6 participants