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

Add Transform Helper methods #15200

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

Bayslak
Copy link

@Bayslak Bayslak commented Sep 14, 2024

Objective

  • The objective of this PR reflects the idea of adding some helper methods to Transform to avoid cumbersome way of providing direction and moving an object. The issue taken in consideration is the following: Helper methods on Transform

Solution

  • I decided to add a basic translate method in the Transform class translate(&mut self, direction: Vec3, speed: f32, delta_time_seconds: f32). This function simply provides a faster way of adding a translation to the Transform by providing a direction, a speed and a delta_seconds (or delta in general referring to time). This doesn't take in account the rotation of the Transform.
  • I also added a second function translate_with_local_rotation(&mut self, direction: Vec3, speed: f32, delta_time_seconds: f32). This function differs from the one above because it also utilizes the rotation of the Transform to provide a way of moving the object following a specific direction and taking in account also it's rotation.

Testing

  • I didn't test the new function, but I changed the example translation.rs using the newly implemented function translate to see if the result was the same.
  • I also tried the second method translate_with_local_rotation by modifing the example 3d_rotation and adding a new line just after the rotation. It moved as expected, but the addition of the line felt like out of scope of the example, so I removed it.

Copy link
Contributor

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

@IQuick143 IQuick143 added C-Usability A simple quality-of-life change that makes Bevy easier to use A-Transform Translations, rotations and scales D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Sep 14, 2024
/// - `speed`: A `f32` representing the speed at which the entity should move.
/// - `delta_time_seconds`: A `f32` representing the time elapsed in seconds, typically
/// the time since the last frame.
pub fn translate(&mut self, direction: Vec3, speed: f32, delta_time_seconds: f32) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should merge direction and speed into a single velocity: Vec3, else we're adding redundant ways to specify speed.

Alternatively if we really want to separate direction and speed (which in my opinion is not a necessary requirement since we multiply them back together anyway). It'd be best to use a Dir3 type for the direction, as it ensures the direction vector is normalised (length 1).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do like your suggestion to be honest.
Didn't think about using the velocity as the result of the multiplication of direction and speed.

Going to implement that straight away!

Refactored the two methods to accept a single Vec3 as the result of the direction Vec3 multiplied by the speed of the entity we are trying to move.

This should remove the redundant assegnation of the speed.
@IQuick143
Copy link
Contributor

Overall I think the code is good, I'm not sure on the naming though.
I feel like translate should take an offset vector, and translate the Transform by that value.
This is more related to velocities and kinematics (moving objects over time).

Not sure what would be a better name.

@Bayslak
Copy link
Author

Bayslak commented Sep 15, 2024

Overall I think the code is good, I'm not sure on the naming though.
I feel like translate should take an offset vector, and translate the Transform by that value.
This is more related to velocities and kinematics (moving objects over time).

Not sure what would be a better name.

I see what you mean.

Maybe to make it more coherent might be better to only have a Vec3 as the signature of the method, calling it translation and let the user create the translation vector by multiplying it by the speed AND the delta time?

@Bayslak
Copy link
Author

Bayslak commented Sep 15, 2024

Going to change it later to only receive a Vec3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Transform Translations, rotations and scales C-Usability A simple quality-of-life change that makes Bevy easier to use D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Needs-Review Needs reviewer attention (from anyone!) to move forward
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants