Please vote on this bug in the issue tracker (Mecanim problem)

The image above explains almost everything. We want to be able to script the playback speed of individual animation states in the Mecanim state machine. This can not be solved using animator.speed or blend trees, if you think that then you have misunderstood the problem. The threads below can explain details in that case.

This feature is widely requested by the community, in these threads, and 100 more that I won't post:
http://forum.unity3d.com/threads/me...speed-of-specific-animation-or-layers.160395/
http://forum.unity3d.com/threads/animation-speed-of-a-single-mecanim-state.241111/
http://answers.unity3d.com/questions/475921/dynamic-mecanim-animation-speedtime.html
http://answers.unity3d.com/questions/367876/mecanim-changing-animation-clip-speed-through-scri.html
There are 10 more pages of these threads in the forum search results.

This feature is simple yet 100% necessary for using the Mecanim animation system to its fullest extent. It is really quite an oversight. Please fix it.

Link to the feature request (so you can vote for it):
http://feedback.unity3d.com/suggest...ayback-speed-for-individual-states-in-mecanim

 

I believe that one of dev mentioned this as one of the improvements coming in 5 to Mecanim. I can't find the post now, but there was list of improvements. Hopefully they will see this post and chime in on what those were.

 

I hope so, thanks. I guess a simpler way to say this is:

Expose the parameters of individual states within the AnimatorController's state machine to scripting.

 

wow really? cant do that? lame! ...
i guess u can make multiple Run animations with different speed settings, right?.... but yeah, that shouldnt be necessary

 

Voted, because i use the legacy Animation system now for reasons such as the above..

 

After what I have experienced with mecanim three days ago, I will forever hate mecanim with the deepest passion and the utmost possible hate. This system shall be boycotted and sent to the British for coasters. That disgusting toenail diseased THING totally made my life 927x harder and I just want to eat a burrito and sh** on that until it turns purple.

 

Personally I think everything in the Editor should be exposed to the scripting API, except for things that get baked into some static data structure. Though, even there, where it's possible I'd like to be able to request updates to the data at runtime (eg: it'd be awesome to be able to move stuff and update the NavMesh, even if we have to async it).

Hey man, don't leave us hangin'! What happened?

I've had my share of Mecanim glitches, though thankfully only one that required any significant rework.

 

Im all ears for what issues you had with Mecanim, but a little more technically specific and a little less foul-mouthed.

 

Yes sorry... I still have dreams about it. HERES the issue. I decide that one of my characters should use another animation from another character. Fine. So I take my animation and remap it to the other character for use. BAM! Whole damn project ruined. Suddenly that whole animation is trash. It wont work on either character. I try everything including reimporting. But I then realize that NO ANIMATION works with my character and it apparently just makes everything trash. Im so tired of this bull that I always have to deal with. Id rather use the legacy animation system (ikr). BTW I was using a model from Unity 3.5 but this model shouldn't have a problem using animations from other models. (Yes they were all humanoids)

 

Ok, Mecanim stopped working entirely unless the animator window is open. Floats on BT randomly stopped working for no apparent reason, which a restart fixed. Automatically changed my rig position, even though the legacy system never did (I didn't really look into the reason why on that one, as I had bigger issues with Unity at the time).

The amount of code needed to get it working is more verbose than just using the legacy system, Mecanim was a bit annoying and had it's bugs. But the thing I scratched my head at was I had little reason to use it over the legacy system.

 

Have IK work in editor scripts so devs can set IK goals and hand/foot positions in editor. Make it easier to find the current animation and transition state without the 2.5 turn somersault. Other than that if you set up Mecanim as a boolean switchboard with blend trees based on floats it is fairly simple 98% of the time to script what is needed. All parameters need exposing. Finding info on any part of the system should take one line of code and be intuitively named..

 

Down with mecanim, up with carrot grade animation systems

 

I see a bunch of people requesting improvements and bug fixing to Mechanim. Why not create an official thread "Mecanim official requests"? So Unity devs can check in one place instead of multiple threads.

 

Ok, Do you still have the project at hand? Which models and animations were you using? Examples?
How did the project get 'ruined'?

For each of these three problems, do you have a project/click-through that reproduces these errors every single time? Do you have examples that you can show in a bug report?

Yup, definitely do this!

 

No, after a ton of other issues (mentioned in several of the UE4 thread on the Unity forums) not mecanim related I eventually dropped unity for our main project and migrated the whole thing over to UE4. I'm still adding polish to a small hack and slash I did in Unity years back whenever I get spare time, thinking about helping a friend out with a text based MMO using Unity.

I'm sorry to say I'm just messing around with Unity now until the subs expire.

 

Fair enough, but unfortunately our developers/support/sustained engineering team need quite a bit more information than 'Floats on BT randomly stopped working for no apparent reason, which a restart fixed' to fix this particular issue. A repro project is ideal in a situation like this!

And sad to see you go! Would you stay on these forums or leave them altogether? Do you have some photos/videos of your project before/after the switch?

 

Yeah the game we were working on is in my signature, I'm still interested in Unity 5.0 so I'm not going anywhere yet .. Also it's not the only project coming up, so you never know.

P.S they might of fixed a lot of the stuff in the later 4.X cycle that's still to come out, I reported it a fair while ago.

 

What? It's not official unless you (Unity) do it.

 

What? A huge reduction in the amount of code required to make things happen is one of the up sides to Mecanim at the moment.

One of the huge down sides is that there's some stuff we flat out can't access, making things far more difficult than they should be, or perhaps even impossible. (Example: When I tried, I couldn't figure out a way to detect when a dynamic transition had ended. To check the state of a transition you need its ID, which you have to query based on its name, and dynamic transitions don't have a name.)

 

Well It's been a LONG time since I used it (Probably 4.2, or even 4.1?), but from the last time there was a lot of stringtohash gubbins in it.. Where as in legacy you'd just use something like animation.crossfade("Wigglebottom")......

It may have gotten a lot better, not sure and can't say in the scheme of things was that bothered.

 

@Andy Touch

I x2 this

Expose animation playback speed at runtime
Expose animation state transition conditions at runtime (I.E. modify an ExitTime condition)
Expose animation clip at runtime (I.E. swap out the "MeleeAttack1" animation clip with another)

Ty

 

It's been a while for me, too. (I made a bunch of generic stuff for my game and haven't had to touch the code since. Which is nice.) The string-to-hash stuff didn't bother me. I think it may even have been optional by the time I used it (4.3), but I used it anyway. (I mean, we're talking about animationThingID = StringToHash("blah"); in Mecanim, in Legacy we have to get AnimationStates and AnimationClips and so on... either way we're managing something somewhere.)

Still, even with that, there was far less code overall to do common non-trivial stuff. Like, a directional blend tree to match walking animations with character movement could be achieved in two lines of code plus two int variables, plus of course setting the state and its inputs up in Mecanim. If you wanted to do the same thing in legacy, you did it all yourself.

 

Its true that Mecanim makes certain things more simple (like blend trees, as you have said).

I think the problem is that you can actually achieve more complex game mechanics with the legacy system, by altering the animation states / clips dynamically,.

Whereas with Mecanim, it isn't the only system that can have a blended walk animation (legacy can too).

The current state of Mecanim is that it's very confining to one style of game, or at least not accomodating to games with dynamic animations (such as any mildly complex RPG or shooter with a weapons system).

 

Well I don't disagree, blending through states in complex animation streams did get a bit cumbersome in Legacy. But still at the time I couldn't find a good enough reason to switch, especially with the issues I encountered. I bet by the time 4.6 or 5.0 comes out it'll be the tool to use..

 

It's certainly improving. I last used it in 4.3 and didn't think it was all the way there yet, though it was already improved significantly over 4.2. I'll probably get back to it in 4.6, and am looking forward to further improvement.

 

I agree entirely, and that's exactly what my experience with Mecanim circa 4.2 and 4.3 was - it makes some things far simpler at the same time as getting you improved results, but there's other stuff that it just flat out can't do (short of resorting to epic hacks... no thanks).

 

Pierre, thank you. I will be looking at this blog soon. Also, I would like you to charge into David's office and put ur hand on his desk, look him straight in the eye and tell him that mecanim should support 2 states running simultaneously. That would be so awesome and I would be saving so much time if this feature could come out. But by the time it does come out, I probably would have been done with my project lol. Anyways... thanks!

 

@Calmcarrots,
An object cannot be in two states at the same time. That's not the way State machines pattern works. You can however have sub-states (that's part of the Hierarchical State Machine pattern).

 

y u do dis unity?

 

What do you mean? How do you even expect that to work? How can you have 2 states at once?

There are indeed variants of state machines where that can be the case, but I'm not sure that they apply here. You can already have different layers and such (eg: different stuff happening on different parts of the skinned mesh), how else would you expect it to work? If someone is simultaneously in two states, what exactly do you expect the output to be?

 

Such as an upper body animation and a lower body animation state

 

But can't we already use the layer system to do that?

 

Idk the thing im trying to accomplish is a bit weird. I dont know how to use the layer system without having to rework my code. Right now, the code I wrote fixes so many problems of mine and it is so easy to use. I dont want to complicate things any further. Its hard to explain but my system relies on more than just the animation but instead uses the information on the animation states and creates the behaviors i want. (It's an AI script btw)

 

I'm having a different problem with mecanim: sometimes the models of my characters/npc are disappearing when they aren't in the camera view and stay invisible. I can hear them moving and attack them etc. But the meshes are not visible.

I could work around this by enable 'always animate/render' but that's not Really a option with many enemies.

Has someone the same issue?

 

That's not the same as being in two states simultaneously. What you want to achieve is "upper body" in one state and "lower body" in an different state (playing different animations simultaneously). Which can be achieved as angrypenguin said, using layers.

 

The thing is that Mecanim isn't an AI system. It's an out-of-scope use case. That's not to say that Mecanim can't be a part of your AI system, but it sounds like it's the basis for one here.

 

It is actually lol. The thing is, if I have my animations control my AI, I can completely forget about programming a full AI system cause the AI im doing is a bit difficult. Im adding as much detail as I can and I would like it to be quite smart. Anyways, I guess I will have to use layers as there is no way I can have 2 states currently. Thanks though

 

Are you aware that there's already systems on the Asset Store to cover exactly what you're doing - AI state machines which can in turn be used to drive animation state machines? It doesn't even have to be an AI-specific state machine.

 

Interesting I will look into that. Thanks for letting me know about this