when updating the rotation/translation of any part in the curve animation editor, it doesn’t respect any manually input rotations that are above/below 180/-180 degrees, normalizing them before updating the rotation. the ability to animate any sort of convincing spin, roll, or intricate rotation is severely limited given this restriction, compounded by the fact that simple addition/subtraction operations can’t be done inside the manual input fields themselves either
Hey, thanks for the report!
This is possibly caused by a few reasons, but the main one is probably that CFrames store orientations as rotation matrices and not angles.
You have to keep in mind that CFrames will interpolate rotations by following the shortest path between orientations. Because of that, you cannot interpolate between two keyframes that are more than 180 degrees apart.
You have two ways of addressing this:
- You can add intermediate keyframes. For instance, to go from -180 to 180 degrees (which are the same orientation), you should add keyframes at, for instance, -60 and 60 degrees. This is probably the preferred method.
- If you are working with curve animations, you can use Euler angles and have only two keys, one with -180 and the other with 180, because in that case the ACE will save and evaluate curves separately. It will not necessarily find the shortest path between the two orientations anymore. Keep in mind though that working with the angles separately might make editing your animation harder, especially when you’re not simply rotating around one axis.
Hope this helps!
2 Likes
thanks for the quick response,
i think the bug/feature incompleteness here is with the interface, not necessarily the ACE or curve animations themselves. ive made maybe a hundred animations with the curve editor since they came out and theyre very capable of handling the type of intricate rotations im looking for, but the problem is that i’ve basically had to calculate the rotations myself to achieve some of the more involved rotations because theres no way to actually input non-clamped numbers into the curve editor except for manually typing in the rotation into the little text field for each axis. to make matters worse, any update to the part with the default rotation/translation tools seem to interface with CFrame-utilizing hard-coded stuff that doesn’t like my inputs and clamps them (demonstrated in the video)
given that the ACE doesn’t need to find the shortest path between orientations, but actually getting the curve editor to use non-clamped angles is such an involved unintuitive process, feels like a really big disconnect between these systems, and thats what im trying to report here. there was a time a few months ago when even inputting big angles into the curved editor wasn’t working–which begs the question of whether support for this use case is even intended in the first place
1 Like
Ah I see. You’re right, the CFrames were never intended to support interpolation for more than 180 degrees. But Studio use CFrames, and in particular the gizmos that let you rotate something will report an orientation as a CFrame. If you look at the rendering of the gizmos, when you rotate something for more than 180, the shaded area will flip. You can’t just rotate for 360 degrees and see the shaded area fill the whole circle.
2 Likes
do you think the engineers would ever update the rotation gizmos to let you wind-up rotations in the curve editor past 180 degrees one day? i think that’d be immensely useful for my workflow and would show off what the curve animator is really capable of in general, i’d make a feature request myself but i’ve been waitlisted on getting that role for the past few months =P
wait i can make feature requests, guess ill do that next
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.