-
-
Notifications
You must be signed in to change notification settings - Fork 21.8k
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
Refactored Node3D rotation modes #54084
Conversation
997853d
to
6625ac3
Compare
As part of the animation team, animators can't read quaternions and rotation modes helps key the proper rotations. Looks good! Will need to wait for tests. |
@fire It is true that animators can't read quaternions. In fact, I don't think anyone really can, but having a quaternion exposed property is great for doing Gimbal-Lock free interpolation (simply add a key in the rotation). I think in a subsequent PR we could have something like a ball you can turn or something like this for editing quaternions but I think its out of the scope of this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fire looked at this too.
Using Hide Whitespace, we validated that the code in set_euler
and get_euler
is identical to before.
It looks great. I was just curious about the DIRTY_VECTORS
case.
Also small nit, but is there any reason to do variant accessors using VariantInternalAccessor<Basis::EulerOrder>
rather than the VARIANT_ACCESSOR_NUMBER(Basis::EulerOrder)
macro?
data.scale = data.local_transform.basis.get_scale(); | ||
data.dirty &= ~DIRTY_VECTORS; | ||
} else { | ||
data.rotation = Basis::from_euler(data.rotation, data.rotation_order).get_euler_normalized(order); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this calculating a new Basis matrix using Basis::from_euler()
when data.local_transform.basis
already exists?
Is this to avoid introducing error when scale is 0 or non-uniform?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is because local_transform may be dirty (invalid)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
Edit: Pending fix for https://github.com/godotengine/godot/pull/54084/files/6625ac317d064c747431ae7b7b2c4df31e948f61#diff-f322b5adb1e36fb871aa172a66a03f9225c591168728c972fd4ceadc3cd3121f, so wait before merging.
6625ac3
to
0ea457e
Compare
A GDScript test is now failing:
|
0ea457e
to
e4b872c
Compare
@akien-mga nice we have this now, let me see if I can fix it |
Now it passes tests, just needs an update to the docs: https://github.com/godotengine/godot/runs/3997580689?check_suite_focus=true |
* Made the Basis euler orders indexed via enum. * Node3D has a new rotation_order property to choose Euler rotation order. * Node3D has also a rotation_mode property to choose between Euler, Quaternion and Basis Exposing these modes as well as the order makes Godot a lot friendlier for animators, which can choose the best way to interpolate rotations. The new *Basis* mode makes the (exposed) transform property obsolete, so it was removed (can still be accessed by code of course).
e4b872c
to
d03b7fb
Compare
Thanks! |
Exposing these modes as well as the order makes Godot a lot friendlier for animators, which can choose the best way to interpolate rotations. The quaternion property is also very handy for tweening without Gimbal lock.
The new Basis mode makes the (exposed) transform property obsolete, so it was removed (can still be accessed by code of course).