The Animation scaling/offset problem

[Beeplets]

Issue Type: Other
Impact: High
Frequency: Sometimes
Date First Experienced: 2020-08-02 00:08:00 (+02:00)
Date Last Experienced: 2021-02-09 19:02:00 (+01:00)

The issue

There’s an annoying problem with playing animations on diffrently scaled characters. For some reason when scaling a character, Animated movement (not rotation) goes completely off. This often goes unnoticed since not many people use uncommonly scaled characters in their game.

This is the character used in our bossfight, I animated this when it was already scaled. As you can see in the clip below, everything seems fine. The animation does what it’s supposed to. The boss falls/rolls over onto his back.

Now upon running the animation using Humanoid:LoadAnimation() in-game, the character gets flung way further than intended and even sinks into the ground.

Originally I thought I made a mistake in the animation itself, but as you can see in the animation editor, there’s no problems there. We also tried anchoring the HumanoidRootPart, but that didn’t change anything.

Upon investigation we found out that this issue occurs on abnormally scaled characters. This problem has occured before and has been for a while. As seen in this post, from 5 months ago. My programmer @0_salcret had this issue on a character that was smaller than normal. When comparing these cases, the character in @0_salcret 's post moves less than expected - this character is smaller. Our boss character as seen in the previous clips, moves more than expected - this character is bigger.

@0_salcret decided to do some testing on this.

Reproducing the issue

To reproduce the issue, he placed diffrently sized characters on a line and applied the same animation to them all. In this animation the character get moved forward and slightly backward. Remember, every character has exactly the same animation loaded into it.

As seen in the clip they don’t move the same distance at all. Especially characters with a bigger BodyHeightScale get an insane increase in moving distance.

_{These numbers are rounded.}

In this image you can see which character was scaled on what. Every character started at x-vector 7, but some ended up further than others. This means that clearly the movement in the animation is being affected by scale, which isn’t something you’d want. Even when animating the character after its scaled it gets offset.

Here are the exact numbers after the animation played:

Here’s a gamefile to test this yourself, unfortunately you can’t play animations by other people. Make an animation that simply moves the whole character forward and see this for yourself.
testies.rbxl (45.8 KB)

Expected Behavior:
I expected the Animation to play with correct translation regarding the scale of the character.

Actual Behavior:
The character gets moved incorrectly due to scaling.

EDIT: Workaround:
Thanks to this reply by @Manelin we found a workaround, but do note that even with this workaround its still problematic and strange that this happens.

When you change the HipHeight of a character to 2, the animation will play out like it should. This is fine for a simple cutscene, but for an interactive boss this could mess some stuff up. The boss’s hip just isnt at a height of 2. When it runs around, because of the HipHeight, the boss will float above the ground. Even with the workaround I think this offset shouldn’t happen.
For non-human shaped characters, like a turret boss in our game and customizable character systems, this might not work.

Thanks for reading

[MyHeadisMelting]

Try using a different function (maybe Animation:Play() )

[Beeplets]

After loading the animation into the humanoid ofcourse you play the animation. The issue isnt caused by any function though. It is mainly the scaling that creates this offset.

[MyHeadisMelting]

oh, have you tried using a custom rig instead of a scaled one?

[Beeplets]

I don’t want to work around it, We need this exact character for the bossfight. besides, this shouldn’t be happening.

[PeZsmistic]

It looks like there should just be a special case for translations on parts rigged immediately off of the root part with respect to adjustments made to accommodate character scale. The animation itself seems fine, only the translation is exaggerated.

[BanTech]

I just discovered this issue on my bowling game. Given how it looks really stupid for the character to cross the foul line, this is quite a major issue…

I might have to force certain proportions and scale, eliminating an entire aspect of character personalisation, probably leading to complaints from players that their scale preference isn’t being used.

It would be good to have some method of avoiding this issue.

[Beeplets]

The only way around it is getting it fixed, It just seems rather strange that translation would get amplified like that. Like you said, this problem may seem minor, but its basically everywhere as long as the animation used in that game moves the character around. I realised yesterday that this problem is actually everywhere in all my games. It’s rather infuriating.

[Beeplets]

Workaround was found, Set the HipHeight to 2. I still think this should get looked at though since it doesnt make sense to have an animation break just because of some scaling. For example people might not want to set hipheight to 2 for programming reasons. Also the thing you talked about with character personalisation, you’d have to test this out, but im pretty sure hipheight might cause problems for that too.

[BanTech]

Might be a case of storing hipheight, set it to something standard (2 in your example), do the animation, then upon completion set it back to what it was to make sure there aren’t any issues.

Thanks for the idea

[0_salcret (salcret)]

I went to test this theory, and HipHeight is definitely a ‘cause’ of the problem.
I didn’t think of this before, but here’s what I just found:

• All of the rigs that move the correct amount all have the same HipHeight. Why? Their new description effects nothing or their width. But not their height.

• The only two that effect the rig’s height, Proportion and Height, have different HipHeights, and are amplifying their translations.

With this in mind, we’ve found a solution, right?
Well- I think otherwise.

With the testing, it works. The ‘Normal’ rig’s HipHeight is 1.8. Set all the others’ HipHeights to 1.8, and the problem is solved:

But as you explained, @BanTech , this problem is occuring with your players. Player characters are non-anchored, and we all know what happens when you lower the HipHeight of a humanoid:

The players would be in the floor. Only way to solve this is to anchor their RootParts when the animation is playing. And that’s not a great solution.

In summary:

I think the problem isn’t too noticeable on player’s avatars, as this bug was found on testing abnormally small and large avatars, and there’s a strict limit to how big or small a player can make their character.
For projects like @Beeplets and I’s, we can make it so the HipHeight changes when playing position dependant animations, though I still think it’s unpractical.

The Humanoid description does not alter the animations, but the HipHeight of the humanoid does. I still belive somebody should work to fix this if not already, but this is all we got for now.

[EmilyBendsSpace]

For a character with a Humanoid, the Roblox animation system currently assumes that animations were authored on a standard-sized R15, with HipHeight of exactly 2.0. When you play a published animation on a Humanoid-based character, animation translations are scaled by the Character’s HipHeight / 2.0.

If you know how to script, you can also scale any already-created animations and republish them. You’d do this by iterating over all Pose instances in the dummy character’s AnimSaves model, and setting Pose.CFrame = Pose.CFrame + ((2.0 / authoredHipHeight) - 1) * Pose.CFrame.p
Where authoredHipHeight is whatever the dummy’s HipHeight was when the animation was created.

[PeZsmistic]

Just to note, this is a non-solution for cases where the character’s scaling can change during gameplay, since that can result in hipheight changing, and is an unpleasant solution in any case. There should never be any assumptions made about Humanoid characters and Roblox should strive to generalize Humanoids completely. Any assumptions should be treated as bugs, and parameters with numbers that do not work for characters of all shapes and sizes and masses should be exposed to developers (like we’ve been asking for years…)

---

Since only the translation of the part immediately off of root seems incorrect, what happens if you modify the rig to include a dummy part between the rootpart and the torso? You never move this dummy part during the animation, but you move torso as normal. Perhaps this works as a workaround.
i.e.
HumanoidRootPart > Torso > ...
becomes
HumanoidRootPart > DummyRoot > Torso ...

[OuterspaceNemo (Nemooo)]

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

[EmilyBendsSpace]

@PeZsmistic

There should never be any assumptions made about Humanoid characters and Roblox should strive to generalize Humanoids completely. Any assumptions should be treated as bugs, and parameters with numbers that do not work for characters of all shapes and sizes and masses should be exposed to developers (like we’ve been asking for years…)

It’s not an assumption about characters, it’s a legacy measurement that became a de facto reference point for animation scaling. There was a point when all avatars did have a hip height of 2.0, and a system was built with no way to encode rig scale with a published animation, because none is needed when you have just one character model.

Would it be an improvement to encode scale of the animation dummy with the published animation, and use the ratio of dummy scale to character scale for retargetting? Yes, of course. But this is a request for an improvement in a feature; it’s not correct to call it a bug, it’s a limitation of an old system. And we’re at a point where there is more than just hip height to consider for proper animation retargeting.

[Minecrablox]

I may found a solution for this, and I experienced a change.

So when I was editing the animation for a large boss fight, translating the edited animation changed the appearance of the normal-sized characters, which is the same result that happened when playing the animation by script on the boss dude.

I made an assumption that by changing the LowerTorso part of the normal-sized dude back to where I want the height to be at, I was able to get this height LowerTorso animation problem fixed.

Demonstrate:

Boss-Sized animation on editor ~= Normal-Sized animation on editor
Normal-Sized animation on editor == Boss-Sized animation played from script

Weird, but somehow it is true.

Boss anim

Normal anim

Even if the size was different, the normal size shows that it is most likely to be the same as when the Boss-Sized character had the Normal-Sized Animation played.

Conclusion: To what it looks like, most of the animation edited on the Normal-Sized characters are the same as if you had increased the size of the character and played the Normal-Sized animation on the Boss-Sized character.

[CookieOdi]

It is 2024 and this issue still exists