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

Rename Velocity properties linvel and angvel to linear and angular #505

Open
Jondolf opened this issue May 9, 2024 · 0 comments
Open

Rename Velocity properties linvel and angvel to linear and angular #505

Jondolf opened this issue May 9, 2024 · 0 comments
Labels
A-Integration very bevy specific D-Easy P-Low S-not-started Work has not started

Comments

@Jondolf
Copy link

Jondolf commented May 9, 2024

Velocity currently has the linvel and angvel properties. This often leads to repetition of "vel". For example, one of the examples in the user guide:

fn modify_body_velocity(mut velocities: Query<&mut Velocity>) {
    for mut vel in velocities.iter_mut() {
        vel.linvel = Vec3::new(1.0, 2.0, 3.0);
        vel.angvel = Vec3::new(0.2, 0.4, 0.8);
    }
}

I find this repetition rather annoying and unnecessary given that the component is already called Velocity. Abbreviating "linear velocity" to "linvel" also doesn't seem useful, and might be confusing to new users. In general, abbreviated type names are not recommended.

I propose renaming the properties to simply linear and angular, increasing clarity and readability.

struct Velocity {
    linear: Vect,
    angular: Vect,
}

The earlier example would look like this:

fn modify_body_velocity(mut velocities: Query<&mut Velocity>) {
    for mut vel in velocities.iter_mut() {
        vel.linear = Vec3::new(1.0, 2.0, 3.0);
        vel.angular = Vec3::new(0.2, 0.4, 0.8);
    }
}

(I would also change vel to velocity, especially in documentation, but that is unrelated to the proposal)

Alternatively, we could split Velocity to LinearVelocity and AngularVelocity like bevy_xpbd, but that would be a larger breaking change and have the caveat of methods like linear_velocity_at_point not really working since they need access to both at once.

@Vrixyz Vrixyz added D-Easy P-Low S-not-started Work has not started A-Integration very bevy specific labels May 21, 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-Easy P-Low S-not-started Work has not started
Projects
None yet
Development

No branches or pull requests

2 participants