0 votes
asked in Bug Report by
When typing in values for localRotation in the Rotation Tool, UMotion is changing the values from the desired values.

For example, I want to rotate the y-axis 90-degrees. I type in 90, but when I hit enter UMotion changes the value for all 3 axes to strange non-90 numbers.

On occasion, the Channels panel allows me to type in rotation values - which stay as inputted - but often that ability to type in rotation values is disabled in the Channels panel.

I'm trying to do this using Euler rotation. The Quaternion Progressive does not allow for typing in values.

I just need a reliable way to type in rotation values that don't change and modify other rotation axes.

1 Answer

+1 vote
answered by Expert (62k points)
selected by
 
Best answer

Hi Vincent,
thanks for the bug report.

When typing in values for localRotation in the Rotation Tool, UMotion is changing the values from the desired values.

For example, I want to rotate the y-axis 90-degrees. I type in 90, but when I hit enter UMotion changes the value for all 3 axes to strange non-90 numbers.

That is by design and is related to the math of quaternions and eulers.

 When I implemented the Rotation Tool Assistant I thought of 2 possible ways how to implement the euler input values:

  1. It would be possible to map the euler values directly to the rotation of the bone (that's how Unity does it in the Inspector). That method heavily suffers from Gimbal Lock effects: That means that it can happen that you enter a euler rotation, but the 3D bone is rotated in a different way then you would expect.
    This video shows this effect in action (make sure to read the subtitles): https://youtu.be/T9Ib7tCawMQ
    And this video explains what Gimbal Lock is: https://youtu.be/zc8b2Jo7mno
  2. So I decided to go a different way on how to implement the rotation tool assistant:
    The values you enter are treated as a delta. Let's say your x rotation is currently 20 degrees and you enter 90. Then UMotion treats that change as: "The user wants to apply a rotation 60 degrees around the x axis."
    So instead of just doing "transform.localEulerAngles = newAbsoluteEulerAngel;" I do "transform.Rotate(eulerAngleDelta);".
    The cool benefit is that in the 3D view, your bone will always rotate EXACTLY the number of degrees you wanted it to rotate. The euler angles are now recalculated to match the rotation in the 3D view. This can lead to completely different numbers than the one you had before.

 I know that both methods are far from being perfect. The real issue here is the euler angles in general. They simply are not perfect for describing rotations in 3D space.

On occasion, the Channels panel allows me to type in rotation values - which stay as inputted - but often that ability to type in rotation values is disabled in the Channels panel.

Rotation properties can only be manipulated directly if they use euler curves. When using quaternions, you have 4 channels (x, y, z, w) and changing those values directly requires some deep knowledge about how quaternions work. Thus those channels are set to read only.

Anyway there is still a way to deal with euler rotations the way you want to: Switching to euler curves and manipulate the euler values directly in the channels view. That's the same as if you would change euler values in Unity's Inspector. But be careful, this can lead to gimbal lock.

I hope this sheds some light into this topic. It's a complicated mathematical problem so I hope I was able to explain this in such a way that it makes sense. Let me know if I should explain anything in more detail or if you have any suggestions on how I can improve UMotion regarding to this topic in the future.

Best regards,
Peter

commented by
Thanks for explaining the reasoning behind the behaviour. Using delta values for rotation inputs makes sense from a programmer's perspective, but is not intuitive from a UI perspective. Perhaps there's a way to better display this in the Rotation Tool?

Perhaps you could allow the ability for the user the choose whether typed-in inputs are absolute or relative? Also the ability to choose quaternion or euler behaviour in the Rotation Tool would be helpful (maybe an option in the Rotation Tool panel options).

I understand the risk of gimbal lock, but as a user I'd like the option to encounter gimbal lock, similar to the way the Unity Inspector works.
commented by Expert (62k points)

Hi Vincent,
I'm also not 100% happy with the current behavior and I'm glad to hear your opinion on this. I like the idea of switching between delta and absolute mode. I will put this on my to-do list with medium priority (because you can use the euler channels as a workaround in the meantime).

Also the ability to choose quaternion or euler behaviour in the Rotation Tool would be helpful (maybe an option in the Rotation Tool panel options).

Do you mean switching the rotation interpolation mode? As this affects the whole rotation curve (and not only the current rotation), I think it might be a bit miss leading if you can change it in the rotation tool assistant.

Best regards,
Peter

commented by
Thanks again for the explanation. I think I now understand the difference between inputting values in the Pose Editor's Channels section and the Rotation Tool. Initially I thought they did the same thing, but now I see that the rotation values in the Channels section corresponds to the values in the Clip Editor's Animated Properties. The Rotation Tool panel is more of a utility to assist when you're manually manipulating rotation with the mouse in the Scene panel.

I think part of the disconnect for me between the Channels section and the Animated properties, was because they're located in two different panels.

Would it be possible to allow typed-in value adjustments directly in the Clip Editor's Animated Properties? Currently the values are displayed, but not editable via typing in a value. It'd be very useful if I could, for example, click on the value for localRotation.x and type in a value.
commented by Expert (62k points)

 

 I think I now understand the difference between inputting values in the Pose Editor's Channels section and the Rotation Tool. Initially I thought they did the same thing, but now I see that the rotation values in the Channels section corresponds to the values in the Clip Editor's Animated Properties. The Rotation Tool panel is more of a utility to assist when you're manually manipulating rotation with the mouse in the Scene panel.

Yes, excactly.

 

It'd be very useful if I could, for example, click on the value for localRotation.x and type in a value.

You can right click on a key, then click on "Edit Key". That opens a small window inside the Clip Editor right next to the key with two input fields (one for the value and one for the frame). Also supports multi selection.

Best regards,
Peter

commented by
Thank-you. The right-click "Edit Key" feature is very useful.

Since you've answered my original question, I'll continue this discussion in a separate Feature Request called "Typing in Animated Properties values in the Clip Editor"

Soxware Support

Here you get official product support by the developer and the community for all Soxware Products for Unity®.

Post as guest, login via Facebook or create an account.

Ask questions, report bugs or provide feedback. Please use the correct category and always post in english.

For private email support, please use the Support Form to create a support ticket.

Copyright © 2017 Soxware Interactive | All Rights Reserved | Impressum

...