Animation Engine - Runtime Changes and Fixes

I’d love to see a repro case for this too.

This sounds like the walk track isn’t getting all the way to weight 1.0. At weight 1.0, no lower-priority track will even be evaluated for the joints that are influenced by the higher priority track. I’d have to see how it’s coded to know for sure what the issue is here.

1 Like

I’m not going to pull up the code as of right now (mainly because its a bit of mess) but I’m pretty sure it was an issue with :AdjustWeight() not working. Animations would work fine with blending enabled as long as the priority was set, however when I tried used adjustweight instead of priority it caused all the animations to blend together instead.

Code was on the client, but I’ll recreate what it looked like

Idle:Play(.2)
Idle:AdjustWeight(0,0)

All walk and run animations played after the AdjustWeight function was used would blend. Maybe the walk/run animations by default had a weight of 1, so it went over 1 thus causing the blending, but it wasn’t something I had tested at the time. And even if it was, the Idle was set to 0, which would still keep the weight of the walk animation at 1, meaning it shouldn’t blend.
That’s all I know of as I only tested it for a short time in an attempt to get it working with one of my projects, hope it was useful though.

Edit; By the way, you should really make priority’s be a number/integer. That way things like a punch barrage for a fighting game could simply add a +1 to the priority until the animations finished, which would solve a lot of issues.

Please do not force the animation blending fix to be permanent in phase 3!

My game relies on the current functionality and there is no workaround. I do not want animations blending overlapping keyframes when one is played over the other. I only want empty tracks to overlap.

Example: I have animation A and B, they are both the same priority (“action”). A animates just the legs. B animates all parts of the player. Players can use these animations individually, but if they chose to use them together I don’t want the legs in animation A and B blended, or they will be at unnatural angles! I want whichever animation was played second to override the previous animation. In the case that B is played first, I want the arms/torso/head to continue to play, and the legs to be overridden. There is no workaround for this! There is no other option to create this effect!

This feature is used to mix animations in the Roblox dance community without the limbs ending up in unnatural directions. It is a feature of my game Dance Your Blox Off (99+ million plays), and my group Focus Dance and Gymnastics (400k+ members). It will be a feature in all sequel projects in this line, as I only intend to make the animation system more complex and increase the possible animation combinations to give players the full freedom to enjoy a fully virtual dance experience.

Could we, instead, have a toggle when creating animations that allows us to chose between blend or override for that animation? This way the new functionality is fully applied, but a new rule is made for specific animations only.

Edit: Another possibility, allow us to change animation priority on runtime, so I can set the new animation at a higher priority with a script!

15 Likes

You are correct that this is a usage that does not quite fit the two intended methods of achieving the desired result. The two ways to do it that use the weight and priority API as intended (and that will continue to work as expected) are as follows:

You can have a hard separation of upper- and lower-body animations, so that you can freely play any combination of them, at the same priority level. This is the preferred solution for when all the available partial body animations make sense to have the same priority, e.g. they are all walk animations.

If the animations are not naturally the same priority, then you could have a partial-body animation play on top of a full-body animation, but that partial body animation would need to be a higher-priority track. This is the solution that’s preferred when it’s clear that the overriding animation has precedence. A typical example would be a full-body walk animation at movement priority, with a hand-waving emote that is upper-body only and temporarily overrides the upper part of the walk animation by being played at Action Priority.

So the question is: what is the best way to make your existing case compliant, and could we do that would make it the most painless. If the situation is that animations are already basically using higher-priority levels than usual (e.g. a walk is Action priority), it seems to me that the least work (for you) would require both an additional priority level above Action, and ideally the ability to override priority from Lua easily without having to republish all the animations. Is this accurate? IIRC, you have a lot of animations in the affected game, right?

The trouble with this one is that the current override behavior, which works most–but not all–of the time in a live game, is just a consequence of the order animations are getting evaluated. The underlying code doesn’t have a stack implementing priority based on playback time, it just happens that there was a bug in the math there newer animation weights were stomping over the weights of already-evaluated tracks, because of a math bug in the blending normalization. In the old system, evaluation order of the tracks matches Play() call order most of the time, because the list of active animations was never maintained sorted by priority for optimal speed.

I think too, that a checkbox for “override” is really just a different UI presentation for “play this animation at a priority higher than published”, so it makes the most sense to me to achieve the end result by allowing higher values of priority.

4 Likes

Bit of unintentional behavior I found with this recent update; I’ll leave a repro save file below (using Roblox’s public animations for this example.) Use the Studio Play option instead of the normal player option so that the animation replicates correctly.

When an animation over the priority of a currently playing animation is played, it will proceed as normal; up until the end of the animation, where the blending of it results in a strange ‘bounce’ effect. I’m seeing animations with the same priority acting as it should, however.

Note that this doesn’t seem to affect looped animations.

Intended effect:
4iX3Ce5rUR
Actual effect:
Exa13DOfpt

animation_blendingissue.rbxl (31.0 KB)

6 Likes

Thank you for this, I will take a look.

Just from inspection though, I can tell you that this is not an expected issue related to the blend fix (which is limited to same-priority tracks). I think there is something slightly off with the fade-in/fade-out behavior in this example.

2 Likes

Just to clarify, those of you who are seeing this “bounce” of the shoulder joints at the end of animations, is it only on R6 avatars?

2 Likes

I used the R6 rig since the global Roblox animations commonly only supported that rig. Though, I have seen this bug occur on every single rig I’ve seen, which includes R15, R6 and non default rigs.

1 Like

In the video I posted, you can see the idle animation skips frames, and the equip bounces.

Sure thing! You should receive it in your DMs.

This is correct I currently have over 150 animations with more on the way. Honestly, if I could just control animation priority with lua that would be fantastic. But I think it would require more than one additional priority level.
Say the player presses animation A and its at “action” priority, then they press B and I script it so that its at the next priority up from “action” (lets call that “super action” priority for lack of an actual term). What happens when the player presses animation C? There’s already an animation at a high priority playing. If I set C to “super action” priority, now I have limbs combining into unnatural angles again.
Players sequence these moves, sometimes very fast. I’d need enough priority levels to keep increasing the chain until all playing animations end, then I could set the priority back down again before the player restarts a chain. Would it be unreasonable to make priority an int value you can increase as high as you need to? (Essentially a Z Index for animations)

There’s a few problems with this.

  1. The issue above, we have a lot of animations. Separating everything would nearly double that count.
  2. Related to issue 1, we have everything keybound which means we can have 20 animations in one keyboard loadout. We don’t have the space to split animations from one loadout further than they are already split.
  3. If we did split them we’d have to remap a lot of the keybinds. This would require players to completely relearn the system.
  4. For future games this is a possible option but it still doesn’t give us the flexibility we currently have for player creativity.

Not going to work because this would prevent some animations from playing when the player presses a key, because a higher priority animation could already be playing.

We’re using the right priority levels for things like walk and idle (“movement” and “idle” respectively). Dance animations are on “action” priority and are all expected to behave at the same priority. They are of equal importance.

No, because they are overriding animations of the same priority because essentially every animation has the power to override every other animation. We need the order they are pressed to dictate their priority, with the last one played expected to play at the highest priority (and its the player, not me, who decides this order).

I might put together a video example of how this works, what our players do with it and why its so important to the community. Our players aren’t just playing a game, their participating in a digital art form. I don’t want to take away a tool they’ve started to rely on.

9 Likes

I can imagine on a larger scale (which it sounds like your game has) is a lot harder to deal with than something like what I’m going to have to fix. So many games have hundreds if not thousands of animations, and this is going to mean a lot of work for those games. Roblox REALLY needs to consider the repercussions of making this not backwards compatible.

While I think this update could work if priorities become integer values, I’d much rather see backwards compatibility, though I see why it isn’t feasible right now. I’m really annoyed that we’re going to have to update stuff again, though. I want to move on from my current project so having to retroactively fix it is certainly a hassle. I just wish there was some way the “standard” behavior without needing customized scripts for it. It has become “normal” after all.

6 Likes

Generally it seems like devs have issues with this feature because they incorrectly play all animations as Action priority and it is a lot of work to update each animation (find humanoid, open in anim editor, change prio, export, find previous export to overwrite).

Couldn’t one solution be that Roblox provides a small tool for mass updating the prio? In an ideal case it would be a list of all anims with a prio dropdown and save button.

3 Likes

Or they could just allow you to change the animation priority in studio/with lua…

1 Like

This isnt even the biggest problem.

The animation fading is straight up broken, resulting in weird bounces when an animations reaches the end.

You cant even fix that yourself.

5 Likes

Please push for integers. I’ve made posts asking for more priorities as far back as 2017 and it’s never been done :sob:

9 Likes

I feel like these updates will be a great implementation. As of now, animation editor has been quite buggy and to be honest, it has been too basic. Overall opinion, this is a really good update!

These changes break the NPC waving animations in Vesteria.

This NPC is supposed to wave at you, but their arm goes back behind their head for some reason. This animation is played at Action priority and the idle animation should be at a lower priority. Looking over our code now I can’t figure out exactly what’s happening but we may be doing something silly like accidently playing the animation twice at the same time. However, the animation works on production and breaks with the new animation engine beta

https://i.gyazo.com/eb0a2ad78e270055e9ece94b12bf3fea.mp4

17 Likes

really weird, something like that also happened to me

Can you send me the asset id for this wave animation? This only looks like a rotation singularity issue.

1 Like

Don’t worry too much about this bounce issue bug, the fix for this will be live well before Phase 3, possibly even 2.

1 Like