Mecanim - Change animation speed of specific animation or layers

Hello,

So I've been trying to port my animation system over to Mecanim but I'm hitting a wall. In the old system, I could go directly to the animation component and set the animation speed as such

Code (csharp):

1. animation["animationName"].speed = somefloat;

However with Mecanim, the only such control I am afforded is through changing the animator component speed. The problem with this is that this variable controls the speed of all animations for that component, not just one.

I was trying to work around this by doing some logic checks in my animation class, and checking to see which animation was playing and then setting the speed as needed. This works fine until you start using multiple layers with the Animator component, at which point the following happens:

Let's say I have a walk animation in my base layer. I then go into my script and check "If the walk animation is playing, set the animation speed = walk velocity". That works fine with one layer. Now, I add another layer, for the upper body. This layer contains things like an attack and hurt animations, meant to be played while walking.

Now this code above doesn't work. Because yes, the "walk" animation is still playing, but so is the hurt or attack animation. The walk animation is meant to have one speed, the other animations the normal speed. I can't seem to figure out a way to fix this at the moment.

Does anyone know if this is even possible with Mecanim? This is a huge oversight if that's the case, but I'm hoping I'm wrong and I just don't know the right way to do it yet. Even a hacky workaround will do, so long as it still uses mecanim.

I'm trying really hard to port my system to Mecanim, and I want to make sure I exhaust all my options before I declare it a lost cause and stick to legacy animations.

 

Hi Rico,

If you go into the animator window (with all your states (walk, run, punch etc.)) and click on the state/animation that you want - 'walk' in this case...in the Inspector window it gives you the option of setting the speed of that particular state/animation. Each state/animation can have its own individual speed setting.

Edit - Also, so far I'm fairly certain that there's no way to alter the overall speed of a particular layer...just the animator component like you described.

I hope this is what you were trying to do!

 

yeah for mechanim inside the controller you just click on the animation and on the inspector you will see the speed like John mentioned, not the whole scripting like animation["animname"].speed that is more for the legacy animations

 

Right, I've seen that . Sorry, I guess to clarify, I'm looking for a way to do this via script, at runtime.

The movement speed of my enemies varies. As they walk or run faster, their animation needs to be sped up accordingly. This was done in the past like I mentioned, though script, using animation["name"].speed = value; However with mecanim I can't find a way to change the speed through script without changing it for all other animations on the component.

 

I don't know if you can set the speed like that, but what I do know is that you can use a blendtree to achieve this:

Maybe you only have 1 walk anim and want to use it at speeds 2-10 m/s. Lets say it's animated at 2 m/s.
Make a blendtree with two motion fields and use the same anim in both, based on a speed float:
anim: walk Threshold: 2 Timescale: 1
anim: walk Threshold: 10 Timescale: 5

Drag you speed slider in the blendtree to preview the anim change speed.
Hope this gives you some ideas.

 

Hey Arnleif,

That's actually an interesting workaround I didn't think of before, thanks for sharing it!

I'll give that a shot to see if it works. Best 1st post ever!

I would still like to see a way to do this through script. It really is almost a necessity when doing steering behaviors for AI.

 

I agree with Rico, even a simple case of two characters walking together- if one is short, he needs a faster walk speed to keep up, but changing Animator.speed makes all of his clips speed up.
It seems silly to have to make a new animator controller just for one clip.

Arnleif's workaround is a pretty good solution for now- just set a bool parameter to trigger the faster speed for my short character.

we need animator.state.speed

 

Arnleif et Al,

Thanks for the Great work around Solution. It worked like Magic !

We are trying migrate our Scrubbing code from the old animation system to Mecanim, was wondering if anyone has some ideas.

Cheers

 

Thanx for this workaround. it has helped me too

 

I was trying to figure out how to do this, and your method works well.

 

I really need to be able to set/modify the playback speed of the individual states from scripting as well.

The method mentioned here won't work for my use, unfortunately. Does anyone have a clue when Mecanim will get ALL variables exposed in the API?
It is very much not in the spirit of "Unity" having so much machinery concealed from a runtime scripting intervention. I need this so(!) badly.

 

i'm pretty bummed to hear that this isn't supported currently. maybe there is a way to access the private variables through reflection? hopefully this is on the roadmap

 

Mecanim needs an overhaul. Since I primarily use Playmaker (which is already a state machine), there isn't a single advantage Mecanim gives me over the legacy system, and it introduces quite a few cons.

Originally I decided to dabble in Mecanim because of the potential of using body masks in override layers. This has proved useless for my purpose as there's (currently) no way two concurrent animations can animate their respectively controlled bones with their respective root transformation/rotation parameters. One root transform to rule them all.

 

Hey all, I know this is old tread but I stumbled upon it having the same problem.

Here is the easy solution.

You can change the speed of the animation in mechanim via scripts.

Animator.speed = value;

By default the value is set to 1, but you can change it this way.

private Animator anim;

Void start()
(

anim = gameObject.GetComponent<Animator>();
anim.speed =2; // this doubles the speed animation for all animations inside the animator of the object this script is attached to
)

 

@Sericet1
Your solution changes the entire animators speed

I'm necroing this thread rather then creating my own because my needs are the same.
The solution of the blend tree is a clever one, but the preferred solution is to change the animation speed by changing the animation state information. Also the change should only applied to a single instance of an animators motor, that is, if my speed is changed only my speed is changed.

 

Come on Unity... Are you seriously going to make me flip through Sprites manually in the SpriteRenderer in order to set a desired animation speed through code? A high level engine like this shouldn't force developers to go back to the basics...

 

Bump

Unity 4.5.0 is out and we can´t change speed of individual animations and/or layers... Please, add this feature on your ToDo list, I can´t move from legacy to mechanim without this feature.

Regards

 

It´s seems that with it works perfectly with blend Tree and Automate Thresholds.

The last time I tried mechanim, blend trees did not work like now.

Regards

 

Please, it's been a very very long time since Mecanim came out. The ability to change speed of individual animation is very important for us to be able to use Mecanim in a meaningful way from code.

 

Wow I am very disappointed to find that there is no way to change the animation speed of individual states in mecanim through scripting.

That is why I too am bringing this thread back to life so that someone from Unity will hopefully see it.

Changing animator.speed is not good enough because it will change the speed of all states. Just because I need a run state to go faster based on a character's velocity does not for example mean that I want their melee attack animation to go faster as well.

Please fix this. We can already click a state in the editor and alter its speed that way, but we need to be able to do it by scripting too.

THIS HAS NOTHING TO DO WITH BLEND TREES, just in case you still don't get it

 

Bump. We have had a lot of trouble justifying using Mecanim because it's vital we can set the speed a state is executing in. Failing this it would be nice to be able to set a motion's speed to 0 at the end of a blend tree as a hacky workaround. Currently this has to he 0.01 which is daft.

This means we can't pause on a ladder at a specific frame depending on speed. Or slow down crawling to a stop. There's a lot of issues here, and it's a woefully incomplete implementation without being able to set the speed of an individual state.

 

We are speaking into Deaf Mecanim Ears. It's already been 2 years. Unity just doesn't care enough about making Mecanim feature complete. It's more about selling the idea of a great animation system and then leaving it half baked. How many more years do we have to wait and how much more money to spend to upgrade in order to get what was promised 2 years ago? Common, it's about time that Mecanim at least match the old animation system.

 

I'd need this feature as well...

It'd be nice if a Unity Dev could tell us if they are planning to implement it (or at least considering to implement it).

 

I'd like to add myself to the long list of people who need this. I've started changing everything to using Mecanim, and now I've run into needing to control speeds of individual animations as well. It's weird that this never was added. Will it come to Unity 5, at least?

 

Bump. What's the point of even using mechanim right now. I've spent the last few days getting everything set up to start using mechanim just to realize I can't even control animation state speed! I mean seriously why is this even still an issue at this point.

 

Bump. We need a fix/solution for this problem.
I can change the animator.SetSpeed for some pre-defined states that require a different speed and swap the value when transitions occurs but it's an ugly and glitchy workaround... and will not work if we have layers.

 

Bump. Any news for a fix or when it will be solved by UT?

 

your method works well.

 

You can do something like this:

//get the current state
var stateInfo = animator.GetCurrentAnimatorStateInfo(0);

if (stateInfo.nameHash == Animator.StringToHash("Base Layer.Idle"))
{
animator.speed = 1;
}
if (stateInfo.nameHash == Animator.StringToHash("Base Layer.Walk"))
{
animator.speed = Math.Max(1, speed + 1);
}
else if (stateInfo.nameHash == Animator.StringToHash("Base Layer.Run"))
{
animator.speed = Math.Max(1,(speed - 2)/3 + 1);
}
else
{
animator.speed = 1;
}

Its not perfect but it works

 

+1 We really really need this!

 

My god.... I just started with Mecanim and this is my welcome news.... no way to control a clip speed... what a joke....

 

I can't believe there's no way to change individual state speed. I hope this is fixed to new unity 5. Mecanim is out since Unity 4, how can such an essential feature is not even in the road map.

 

Just wanted to bump this up as well... I'm at the state of my development where I definitely need this feature. I know it probably won't come in time for implementation in my current project but it would definitely be nice for a future project to be able to set the animation speeds for layered animation.

 

It looks like it may come in 5.1 (so in a long long time ) : http://forum.unity3d.com/threads/pl...-tracker-mecanim-problem.259533/#post-1730887

 

Bump. I need this too. If you want this feature. Vote it up in the feedback form:

http://feedback.unity3d.com/suggest...ayback-speed-for-individual-states-in-mecanim

 

A unity developer got back to me after i've forwarded this thread and said that they know about it and is indeed ready, should be deployed with 5.1.

Btw @Phong , really like that fast shadows of yours.

 

If it is ready why wait till 5.1? What about a hotfix? At least adding it to 4.6. That is a "feature" (that isn't really a feature... I thought it was common sense) which belongs to Unity 4.x.

 

Dunno. I'm just saying what i've been told. Most probably there are background changes that need to be made first in the rest of the system for it to work and can't allocate people atm to work for that cycle. Dunno. Perhaps it will be updated in the 4.6 as well down the line.

 

http://answers.unity3d.com/questions/391388/workarounds-for-per-state-animation-speed-control.html

workaround script I came up with for dealing with time-scaling using blend trees

 

+1 I was shocked to find this thread and realize that what seems like a basic behavior is not supported in Mechanim.

 

Add me to the list. Unity itself is a pretty huge joke to me and I've been using a few game engines. Now, there are still a few good sides to Unity but overall it lacks many of the professional game engine boilerplate features. I will advice not to use Unity as much in our team (although we actually just started..)

 

There is just no excuse for this. Pretty pathetic, honestly.

 

There is the power of open source.

 

1st day i'm using a strong opinionated engine such unity3d, and i've encountered this issue as well. never found such obstacles using other non-opinionated engine until now.
even my own animation library support individual clip speed, come on unity....you must be joking!

 

Opinionated? An interesting description, but accurate I think. Unity's mindset appears to have aligned with Microsoft's attitudes over Windows 8. They think they can predict how we want to use their software, then force us to use it only in that manner. Well, Unity doesn't get to decide the needs of our projects. Unity's job is (or was) to make their toolset as flexible as possible, empowering us to implement any features we need.

 

They *are* trying to fix it. I'm not saying it's great, i'm just saying that they might have not seen it coming the way it has.
Perhaps that's why the legacy system hasn't been removed yet.

 

Yeah, I'm stuck as well -> Please if anyone could help me achieve this type of motion:
I use one 2d simple blend tree to manage idle and run animations in any 2d direction. The tpp character needs to be always directed back to the camera so if we press back button he needs to run backward. Everything works fine until player run back+left or back+right directions ... Proper blending is impossible until run_left and run_right animations in blending tree are inverted when player z velocity component is < 0 - which i found impossible to do in runtime
What can I do to keep this type of locomotion in one blend tree ???

btw.. Inverting whole animator speed ( to -1 ) resolves the problem but it's so nasty hack .. what if I want to run back and make punch attack forward ??

 

Mecanim is proving to be almost unusable beyond fairly trivial cases (and the simplest cases are best handled by the legacy system, IMHO).

No way to dynamically load/change clips (without resetting the entire Animator), no way to set the position within a state from script, no way to change speed of an individual state/layer, and some most un-Unity-like hassles with state name hashes (rather than strings) and their unclear naming conventions.

If it wasn't for the usefulness of retargeting and anim-driven motion, we'd abandon it entirely.

Fairly simple use-case: I want to be able to control the speed of a lower-body walk animation, while playing an upper-body attack animation at it's default/intended speed.

Right now I'm seriously considering attempting to mix Mecanim and legacy anims by having two skeletons in the scene (one Mecanim, one Legacy), with one being invisible - and manually blending transforms from the two in LateUpdate...

 

@bluescrn As far as i know, they'll eventually abandon the legacy system altogether.

 

That may have been their plan originally, but I can't see it happening any time soon. They know that most users still rely on the legacy system to some extent.

Maybe a compromise would be to provide a legacy-style interface for playback of Mecanim animation data (with retargetting, but without any of the state machine stuff). Then they could lose a lot of the legacy stuff, without it being a big step backwards in functionality.