Calinou
commented
6 months ago Open imirui opened 6 months ago
Calinou
commented
6 months ago 
TokageItLab
commented
6 months ago It appears to have a different use than #9215.
This is more likely a function related to Node3D's RotationMode. Wouldn't keying with Node3D's RotationMode set to Quaternion solve this? Although, keying from the inspector for the Node3D transform depends on the RotationMode, so it might be confusing to change it frequently. This is because it is impossible to animate a Node3D object in Euler mode with Quaternion keys.
Well, since inspector have an Editor for Quaternion except for the Node3D properties, should we make that visible in Node3D as well? This will make it a little more comfortable for users to use Quaternion regularly. I remember hiding it to avoid confusion with RotationMode in https://github.com/godotengine/godot/pull/64691.
This is because it is impossible to animate a Node3D object in Euler mode with Quaternion keys.
One thing that makes this possible is the Rotation3D track.
So it might be possible to provide an option to insert the track as a Rotation3D track in the dialog, just as it is possible to insert it as a Bezier track. This would be another solution if QuaternionEditor should not displayed in Node3D.
rossbridger
commented
1 month ago I did notice that imported Mixamo animations appear off if the character model's rest pose is not T-pose. Is this issue related to the phenomenon?
Describe the project you are working on
I am making a 3D FPS game with viewmodel animations.
When making an animation, I do things frame by frame. I manipulate the models, insert a key, and repeat until the animation is completed. I prefer to use absolute space when changing positions and rotations of models, rather than local space because I just find absolute space easier for me.
Describe the problem or limitation you are having in your project
If I move any node that has a rotation property in a way that causes the degrees of any rotation value to change signs, the model will do a quick yet annoying rotation to move to the new keyframe. This is annoying as it can be difficult to tell if I should add or subtract 360 or 720 from each value in the keyframe editor by just looking at the rotations alone.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
My suggestion is for an option when making an animation or editing an animation to allow the animation to use absolute space for rotations. This will wrap the rotation, keeping each value of it in the range 180 to -180.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
When interpolating from one rotation to another, it will seek the shortest path to the keyframe's values, accounting for wrap as well. For example, if you want the rotation of a cube to go from 170 to -170, it will increase to 180, wrap around to -180, and continue to interpolate to -170. This is similar to absolute space transforms in the editor, where it wraps around to -180 and continues the rotation.
If this enhancement will not be used often, can it be worked around with a few lines of script?
This can be worked around by adding or subtracting 360 or a multiple of it from the value of the rotations in the value editor on keyframes. This is not as convenient as my solutions, as you have to type "+360" or "-360" at the end of every axis' rotation if it wraps around.
Is there a reason why this should be core and not an add-on in the asset library?
This should be a core feature as it will help people who use absolute space editing animate faster. It will also help people porting over key frames from other software that may use absolute rotations to complete the animation faster, eliminating the need to add or subtract 360s and 720s to the rotation of an axis. It will also help people who are new to Godot, with them not asking the internet why their model is doing its best impression of a gymnast and doing complete front flips and back flips when moving from one key frame to another.