Broken `Instance` hierarchy for `CurveAnimation`s

KeyframeSequences use an Instance hierarchy to determine which Motor6D a Pose’s CFrame is applied to when playing an Animation. The hierarchy itself is poorly documented, so I will briefly describe its intended behavior as seen in KeyframeSequences. A KeyframeSequence is composed of several Keyframes, which are themselves composed of several Poses. Poses contain the CFrame values applied to the Transform properties of their corresponding Motor6Ds. Which Motor6D a Pose’s CFrame value is applied to is determined by the Pose and its Parent’s Names. The Pose’s CFrame will apply to the Motor6D whose Part0 and Part1 share names with the Pose.Parent and Pose respectively. These rules result in a parent-child hierarchy starting with the HumanoidRootPart and progressing through all of the other joints in the rig. This system is unnecessarily complicated: it would have been much simpler to have no hierarchy and simply have Poses share names with the Motor6Ds themselves, but the system works on KeyframeSequences, and changing it now would be impossible. The same can not be said for CurveAnimation hierarchies. For background, CurveAnimations use Folders instead of Poses as the main component of their hierarchies. If a Folder exists within the hierarchy with a proper Parent and Name, then the Motor6D will be transformed not using the data from aforementioned Folder, but the first Folder descendant of the CurveAnimation with the same name as that Folder, which does not always match. This is the bug in question. The bug is demonstrated in the attached repro file using what I have dubbed a multi-animation, which is a single AnimationClip that plays the same on both R6 and R15 rigs by essentially merging the animation data for two rigs into one. The animation itself is based on an R6 KeyframeSequence with three Keyframes that rotate the head 90 degrees and back. This KeyframeSequence was copied into a new CurveAnimation using the built-in Roblox animator. Both of these original animations are present in the AnimSaves directory in ServerStorage. Furthermore, both animations were copied again and converted into multi-animations using my plugin. When playtesting the game, there is an R6 and R15 rig that play the same Animation simultaneously. Use the button on the left to cycle between playing the KeyframeSequence and CurveAnimation multi-animations. The KeyframeSequence will play correctly, but the CurveAnimation will never play correctly on both rigs at once. The button on the right (which you may need to click twice the first time) reloads the animation after reparenting the R6 and R15 components in the multi-animation as to change the internal descendant order of the Head Folders. The rig playing the animation incorrectly is doing so because it is using the Head Folder that does not match the hierarchy, because the one that does match the hierarchy is the second descendant with the name Head. It is critical to note that the animation playback changes only due to changes in the internal descendant order, which is the only thing clicking the right button modifies about the animation, and is not correct behavior.
CurveAnimation repro.rbxl (88.7 KB)

Expected behavior

To summarize, CurveAnimation Folder hierarchies should function the same as Keyframe Pose hierarchies.

I tried to make this report as clear and as detailed as possible. If need be, I can answer any questions about this bug or create additional repro files.

2 Likes

Thanks for the report! I filed a ticket in our internal database and we’ll follow up when we have an update for you.

Hi, thanks for your report!

You’ve discovered a subtle bug in the way CurveAnimation channels map to joints in character rigs. You have the right idea in that CurveAnimation should match the hierarchy. Thanks to your repro, we’ve identified a case where the channel instances internal order played a role on which channel would get mapped to a specific joint if they had identical names. Instead, identical channel names should be disambiguated by where they are in the hierarchy.

A fix has been made and it should be turned on in over the next few weeks.

1 Like

Glad to hear it, I’d like to ask you to reply here once again when the fix is deployed if you don’t plan on doing so already.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.