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.
Velocitycurrently has thelinvelandangvelproperties. This often leads to repetition of "vel". For example, one of the examples in the user guide: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
linearandangular, increasing clarity and readability.The earlier example would look like this:
(I would also change
veltovelocity, especially in documentation, but that is unrelated to the proposal)Alternatively, we could split
VelocitytoLinearVelocityandAngularVelocitylikebevy_xpbd, but that would be a larger breaking change and have the caveat of methods likelinear_velocity_at_pointnot really working since they need access to both at once.