Mecanim and default values

May 30, 2014 in Technology

Hi there,

we are looking into how Mecanim handles its default values and  wondering if we should change it in the future.

Let’s get a bit technical!

The way that Mecanim currently works is that if a “property”– position, rotation, scale, float, animator parameter etc. – is animated by an AnimationClip in an AnimatorState, it will always be controlled by the Animator. This means that when transitioning into some AnimatorState that does not have an AnimationCurve for that “property”, it will be forced to its default value.

About this approach:

Pros:

  • States don’t have to handle default values themselves. So no need to clean up values at the end of the AnimatorState.
  • The current value of a property does not depend of which AnimatorStates were previously visited.

Cons:

  • Counter intuitive to have values forced to their defaults when not animated in an AnimatorState.
  • No way to have an empty AnimatorState that remembers the last pose/animation/sprite.

Do you see others pros and cons?

Our idea is to change the default behavior so that properties are not forced back to their default values when not animated.   How does that sound?

We could then offer the option to force write back of default values (like the current behavior).  We think of putting the option in the Animator itself.  Do you have uses where you would like to have a finer level of control over this?

Thanks for your time!

Comments (45)

Subscribe to comments
  1. Imi

    June 23, 2014 at 10:43 am / 

    I really like the idea of allowing mecanim to not touch unanimated properties. This is an additional important step towards making mecanim an universal state machine system manipulating other things that just animations.

    for the “finer grained” control: I can’t think of a good practical use of that, so I guess its ok to leave it at a global per-controller level.

  2. Pierre-Paul Giroux

    June 20, 2014 at 2:24 pm / 

    @Emil : agreed. The idea is to blend in the transition.

  3. Emil "AngryAnt" Johansen

    June 18, 2014 at 12:50 pm / 

    @pp: Regarding the cross-fade:

    What I’m saying is that as Rune suggests, cross-fading from current to default value, when transitioning into a state that would have the default value set, is much nicer behaviour than just immediately setting the default value.

    This way you can stay productive and avoid seeing lots of characters pop when you hit a not-so-often-used transition at some point knee deep in state machine design iterations.

    It is nicer default behaviour to cross-fade than it is to directly set, is the point. Just like logging an error is nicer runtime behaviour than a hard crash.

    Though you’d of-course prefer the erroneous scenario to never happen, once it inevitably does, logging is preferable to crashing.

  4. Pierre-Paul Giroux

    June 16, 2014 at 12:16 pm / 

    @PAUL SOUTHWORTH
    Im not sure I understand what you are talking about regarding how you wish transitions would work. Can you give me more details, or maybe an example ?

  5. Paul Southworth

    June 14, 2014 at 8:10 pm / 

    On the other hand i do with i could of seen the crossfade function inside mecanim to behave similar to how it was on the legacy system.

    For example on the legacy system implementing a parameter value in this case a float would decide how fast to transition to that animation yet it is being called in the update function and it does seems that natively it uses that value once as it should.

    Yet on the mecanim system using a value in which does makes a blend and transition if it’s being put into the update function it will be called every frame thus making the animation not really play but stay trying to transition every frame.

    For a workaround for that second parameter which would be the amount of transition i have to create some more variables to make checks such as lower the value at runtime in order to get it to work and i had to make checks whether that state is in transition.

    In a way it is counter intuitive since it would be dealing with several animations, yes i can counter act it by instead making transitions visually on the controller.

    In my current case i’m attempting the transition into using the generic feature.

    Now Back to the main subject yes it would be nice if creating and empty state could remember the values of the bones and of the such since it’s a quick and robust way to create a clip for transitioning or a form of empty idle animation in terms of using generic such as fps hands when creating a shooting game and probably the 2d animations would defenetly take advantage of it.

    Thanks for reading if you do so and I apologize if the subject strayed a bit from this main blog.

  6. Arnaud

    June 13, 2014 at 3:49 pm / 

    Personally, I’m against forcing default values. This is a pain when animating anything else than an avatar (GUI, mechanical equipment, etc, which have different states).

    The gist of it is that you are forced to explicitly create in Mecanim the whole behaviour of the object. But we already have tons of tools to do that (in-house, spaguetti machine, playmaker, uScript, Behave, etc). And then instead of just playing an animation, you have to re-create the exact same graph in Mecanim.

    I did read that Mecanim will provide events in 5.0. I just hope you don’t expect it to be the foundation for AIs and StateMachines.

  7. Pierre-Paul Giroux

    June 4, 2014 at 10:05 pm / 

    @MATTHEW
    In 5.0 we have StateMachines transitions. Where you can define transitions in between StateMachine. This is implemented with Entry and Exit nodes in the StateMachines. The Entry acts as a logic node.

    If I understand correctly this would fix your problem ?

  8. Pierre-Paul Giroux

    June 4, 2014 at 10:02 pm / 

    @MATTHEW
    To swap animations at runtime you should use this : http://docs.unity3d.com/ScriptReference/AnimatorOverrideController.html

    @ELI CURTZ
    Interresting idea, but for me the fact of seting or not back to default is not something that is done by the animationClip but it’s done by the Animator. Any use case where you think its better to have it set in the AnimationClip

    @Emil
    Yeah, I think State is the good place to set it aswell. And I agree that default setting should be as it is now.

    “xcept I quite like Runes idea of cross-fading that reset rather than a direct set. If you truly care about the transition, you should have animated it in the first place. Cross-fade is a “safe” default”

    not sure I unterstand this.

  9. Emil "AngryAnt" Johansen

    June 3, 2014 at 11:55 pm / 

    @pp: Something like a “reset unhandled to default” toggle per state (enabled by default), which if enabled would result in the current behaviour of resetting to defaults when transitioning into that state.

    Except I quite like Runes idea of cross-fading that reset rather than a direct set. If you truly care about the transition, you should have animated it in the first place. Cross-fade is a “safe” default.

    Similarly the toggle should be on by default, enabling the reset, as it too is the safer default – leading to lower complexity vs. debugging poses stemming from accumulated changes.

    And again, the toggle has to be on the state level as the component-level toggle suddenly opts you in to the complexity when you need that behaviour for a single case. Or worse – if by default you have no reset – you need to struggle with the complexity throughout development, until you find the toggle to turn it off.

  10. Eli Curtz

    June 3, 2014 at 8:46 pm / 

    Couldn’t this be implemented via the already existing wrap modes of “once” (values return to default) and “clamp” (keep the values at the end of the clip)? Of course the current clips have all been built with default values for all of the muscle curves, so those would need to be cleaned out.

    My current issue with the mecanim defaults is that the mandible muscle is defined as jaw close rather than jaw open, and therefore the default value of 0 means everyone looks like Cletus, the slack jawed yokel. (Bug 605444).

  11. Matthew

    June 3, 2014 at 4:50 pm / 

    @Pierre-Paul Giroux
    Heya paul

    1) Its not that I want to create states at runtime, I want to change animations within those states. Imagine an RPG, 30 characters all have the same state graph but use different animations. Now we have a situation where we have to dupe the state graph to swap animations rather then switching them out at runtime.

    2) Mechanim dosn’t seam to be event based, but poll based. Imagine this scenario:

    I have an “attack logic node” that is empty (no anim) I just use it to create logic between states. (makes complex combat manageable as I don’t need to create transitions and custom logic between every possible animation combo, think fighting game). So I have attack 1 and attack 2. The graph works like this. I’m in “attack logic node” If bIsAttacking and intAttackNum == 1 I can transition to attack 1. Attack 1 can transition back to “attack logic node” if bIsAttacking == false. Problem is if bIsAttacking is set to false and then back to true in the same update, BEFORE mecanim transitions to “attack logic node” the system would break.

    We only have two solutions currently that I can figure out; to create logic between attack 1 and attack 2 and every other attack transition(overly complicated) or to put an update of latency into the game system (can break combat in a game like Street fighter where 1/2 frame changes balance).

    Does that make sense?

  12. Pierre-Paul Giroux

    June 3, 2014 at 4:21 pm / 

    @MATTHEW HOESTEREY
    “Need to be able to ignore the editor entirely and build state graphs in code. (or change out nodes in code) This is a huge problem when you have a large number of characters with similar but slightly different logic as it creates redundancy”
    You want to be able to create States in Runtime ? or simply blending graphs ? Im not sure creating States at runtime makes sense. As for Blendtrees, we are looking into that! We have a new type of BlendTree in 5.0 that allows to fully control the weights of you animation in it. That is a first step.

    “There is latency created when going back to empty nodes creating inconsistent behaviors. (E.g. idle -> logic node -> walk) would not happen in one update.”
    Not sure I understand, can you detail more please.

    ” we don’t have enough control on how states switch. Need the ability to force state transitions (tied to the above)”
    Animator.Play and Animator.Crossfade do exactly just that no ?

  13. Felor

    June 3, 2014 at 12:14 pm / 

    How would this work with Animator’s layers?
    For example now if we have Nod animation where only head bone has animation Mecanim give default pose to all the other bones. This problem can be solved by give mask for layer. But problem in this solution is that for example hand wave animation need also it’s own layer with it’s own mask. This quickly result over complex animators and probability for user mistakes comes higher.

    My suggest is keep old default valuing on Base layer. And on Layers inherit value from Base layer if value is not set in the animation.

    Would you think this could be reasonable approach for animation behavior on layers ?

  14. Matthew Hoesterey

    June 2, 2014 at 5:25 pm / 

    The option would be nice,
    Overall I like to see the system opened up to the API more.
    -the entire system of having “animator” variables is problematic and hard to manage for large products. We really need to be able to drive more from code for larger projects.
    -Need to be able to ignore the editor entirely and build state graphs in code. (or change out nodes in code) This is a huge problem when you have a large number of characters with similar but slightly different logic as it creates redundancy.
    -There is latency created when going back to empty nodes creating inconsistent behaviors. (E.g. idle -> logic node -> walk) would not happen in one update. This drastically increases complexity of the state graphs.
    - we don’t have enough control on how states switch. Need the ability to force state transitions (tied to the above)

  15. Tim

    June 2, 2014 at 2:01 pm / 

    I was on a similar track as Emil.

    The problem with putting this kind of flag at the higher Animator level is that the Animator is meant to be generic. You’re forcing every possible implementation to follow one approach.

    In the case of our tool (Motion Controller), I’m looking to merge sub-state machines from multiple authors. Each author could have a different need for the states in the animation flows they create.

    A per state option to write back defaults (if needed) would be much more flexible.

  16. Pierre-Paul Giroux

    June 2, 2014 at 12:49 pm / 

    @Emil : So a per State option – something like write back default values when not animated ?

    @Dean: But what you are suggesting, the parameters are always reset to something when not animated ? either it is sceneframes or default values. The idea here is to have values not reset and keep their last evaluated value.

    @arthur : to my knowledge, all asset bundles bugs have being fixed. Please file me a bug if you still have them in 4.5.

    @richard: not sure keyframe types is a good approach. A lot of the animations come from an external DCC tool ( maya,mobu,blender) where these types does not exist.

    @will brett : we have something for that in 5.0- its called StateMachineBehaviours which allows to have a callback on OnEnter/OnUpdate/OnExit. Stay tuned, ill have a blog post up that details the good stuff Mecanim has in 5.0.

    @robin: yes. we want to look at fixing that real soon.

    @malo sal: we are having this discussion because many people have reported the system to be broken because of default value enforcing.

    @sliced3d: in 5.0 you will be able to create the whole FSM via script. However you won’t have “yet” the ability to write your custom blending nodes.

    @partel lang : this is actually a very good idea. The thing is, the mask currently only supports transforms. We would need to expand it to support all animated properties ( ie Sprite renderer)

  17. Pärtel Lang

    June 2, 2014 at 11:09 am / 

    What about the performance? Isn’t the current solution wasteful as it is always animating all the channels, even when currently in a state that is changing the rotation of a single bone?

    We already have a Mask option for each imported animation clip, so why not use that to determine, which bones should be defaulted/animated and which ones completely ignored by that clip?

    So if a bone is checked, it will be animated and if there are no curves for that bone, it will be defaulted. If the bone is unchecked in the mask, it will not be animated nor defaulted.

    By default all the bones are checked anyway so this should not mess up anyone’s work, but still give the most precise control over this – not component-level, not state-level, but transform-level.

    AnimationClips created in Unity, that don’t have a mask, should be not defaulted in my opinion.

    Cheers,
    Pärtel

  18. slice3d

    June 2, 2014 at 4:41 am / 

    I’d like to have a finer level of control by having the ability to write my own custom nodes for Mecanim from scratch (C# + Mecanim Node API) and use Animator editor as a handy tool to visually build FSM systems out of these nodes to avoid confusion when animation systems becomes too complicated to understand, edit and debug without the ability to visually control the way they built.

    Is it possible that someday we’ll see _such_ level of control for Mecanim in Unity instead of having the black box as it is for the moment? Because that’s the reason why am I currently stick to the legacy animation system in my Unity projects.

    Thanks!

  19. malo sal

    June 2, 2014 at 4:17 am / 

    Don’t fix whats not broken. Plain and simple. It works fine the way it is, so why fix it and make users have to read more documentation? I hope you leave it the way it is.

  20. Robin

    June 1, 2014 at 11:17 pm / 

    One thing will be cool, is to have acces to curves at runtime, being able to modify keys of existing curves in a AnimationClip.

    I’m not sure why this feature doesn’t exist yet but it’s very sad….

  21. Rhys Thompson

    June 1, 2014 at 8:57 pm / 

    Surely if you aren’t sure which, a checkbox to choose one or the other would be best? That way everyone can have it the way they want. And you already have one method coded so there isn’t much sense in getting rid of it if it might be what some people want.

  22. Will brett

    June 1, 2014 at 8:50 pm / 

    Unsure but would really like a way of checking if an animation is finished. That’s the most frustrating thing about mecanim for me

  23. Richard Fine

    June 1, 2014 at 7:12 pm / 

    Interesting…

    It’s definitely useful to go back to a default state sometimes, so I think that as far as the question posted in the OP goes – “should we keep the behavior” – the answer is a resounding “yes, in some situations.” So now it’s just a matter of what API/workflow/control is given over this.

    Knowing that the animator rebinds defaults on activation is particularly interesting with regards to some recent discussions about the lack of ‘dynamic start values’ in Mecanim…

    Starting to think that we need the concept of ‘keyframe types’ – we’ve got ‘explicit’ at the moment (i.e. at time T, use explicit value V) but we also need ‘default’ (i.e. at time T, use the default value) and ‘atStart’ (i.e. at time T, use whatever value it was at the beginning of the animation). So if you want to return to the default position in an animation, you just give it a flat curve with a couple of ‘default’ keys; similarly if you want it to just hold position, you give it a flat curve with a couple of ‘atStart’ keys. This gives us per-state control; then you can have an Animator-level option for which behavior to use if the clip contains no curve at all.

    Combine this with an API for updating those default values (maybe Animator.Rebind already does this? The docs aren’t clear) and I think it’ll solve a number of the issues.

    (Of course, if you /really/ wanted to go nuts then you could give us a fourth keyframe type – ‘parametrized’ – and let us link the value to an Animator parameter. Then we could define e.g. animations that do color tinting of a UI button, but have the actual color values be fed in as Animator parameters, allowing us to alter the colors used for a specific button without having to mess with any animations – defining curve shapes but not specific/absolute values. In this scenario, the ‘default’ keyframe type would just be a special-case of a parametrized key).

  24. ugur

    June 1, 2014 at 5:57 pm / 

    I’d like it as option which one can easily turn on for mechanim setups and classic animation clips (there probably in the first frame for a property), too, where the default would be it starts at the default offset but when one chooses an alternate option like let’s say dynamic offset or something like that then it would start off from the fitting time offset like in your prototype.

  25. Arthur Goikhman

    June 1, 2014 at 3:36 pm / 

    For us, the biggest issue with Mecanim (pre-dating 4.5, at least) have been problems with putting controllers in bundles, even though nominally fixed, it’s causing crashes, so for now, we’ve settled on including all the key controllers and animations in the base build, which is suboptimal.

    Since the intro of direct Play transitions, we have not lacked for any other major feature, though tighter integration between the navmesh agent and the animator would be welcome

  26. Dean

    May 31, 2014 at 11:41 pm / 

    I think of it as if you was using containers, animatable properties make up keyframes, keyframes make up an animation clips, Unity uses the animation clips to define the animation state at a given point in time.
    If you had a level of markers that sat on top of the animation clip, eg.(sceneframes!!? a made up idea!) then you could set them manually if you wanted a default position(the start of the animation clip, resting position) to return to, or an end point that could hold the last ‘sceneframe’ (the last animated point within the clip, not necessarily keyframed ) at an open point. If you didn’t set these then the unity function would default to its current state. I think that would be the best of both worlds.
    My previous comment was in terms of other applications which made it confusing, I may have still missed the point.

  27. Emil "AngryAnt" Johansen

    May 31, 2014 at 11:13 pm / 

    I am all for adding the option, but concerned about ending up spending a ton of time debugging weird corner case poses and behaviour stemming from accumulated changes.

    Ending up in that territory because I needed this behaviour for a handful of states would be annoying enough that I would simply avoid using the option.

    Why not have it as a per-state option in stead, so I can limit the complexity of its impact vs. being a component-level option?

    Defaulting to cross-fading to default values as Rune suggests, in stead of snapping, also seems sensible. If I specifically wanted snapping behaviour vs. simply not paying mind to it, I should animate it so.

  28. Pierre-Paul Giroux

    May 31, 2014 at 10:10 pm / 

    @Dean :

    Not sure I fully understand, what you are saying is that going back to the deault values is something that you want to decide “when” you want to do it?

    For example you can have a state with a single frame animation that restores everything to its default values ?

  29. Pierre-Paul Giroux

    May 31, 2014 at 10:06 pm / 

    @KYLE
    “1.) An animation with a single event doesn’t seem to fire the event unless you add at least one curve.”
    Yeah we don’t handle that. What is the lenght(duration) of the AnimationClip in the case you only have events on it ? I would say the last event time ? So yeah, until we change that, you must have curves so that the animationClip actually has a duration.

    “2.) There is no way to set the timescale individually for an animation controller. Many people have run into issues with “pausing” by setting timescale to 0 and then needing to animate something while the game is paused.”
    In 4.5 the animator has a setting called Update Mode, where you can set it to be independent of the timeScale -> Unscaled Time. You want to use that when paused.

  30. Kyle Nunery

    May 31, 2014 at 9:56 pm / 

    I agree it’s unintuitive that the default state is restored when transitioning to a new animation. I a have found myself in the situation where I just “hid” my object by disabling the sprite renderer in the last frame of my last animation and now the object is visible in my new animation state. This can definitely be worked around but is unintuitive the first time you see this.

    Other unintuitive things I have experienced with the animation system.
    1.) An animation with a single event doesn’t seem to fire the event unless you add at least one curve.
    2.) There is no way to set the timescale individually for an animation controller. Many people have run into issues with “pausing” by setting timescale to 0 and then needing to animate something while the game is paused.

  31. Jim Thomson

    May 31, 2014 at 9:19 pm / 

    I vote for making the option available to not restore default. But keep the restore defaults setting turned on as the default setting.

  32. Joachim Ante

    May 31, 2014 at 9:12 pm / 

    @Richard:
    “The biggest problem AFAICT is that I didn’t even know this behaviour was present – I was aware that parameters would return to default values if not animated by a clip, but not all curves. What default values get used? When and where are those defaults set”

    Default values are extracted when binding the animator by sampling all the components. So the default values depend on the instance.
    Binding happens when the Animator is being activated or loaded while in active state.

  33. Dean

    May 31, 2014 at 9:04 pm / 

    It may be the way I work but I’ve always found it a nuisance in animation that you cant capture an ‘empty’ keyframe, you have to move something for it to become animatable. Before I start to even animate I like everything to be captured so that every part of the default ‘character, object or whatever is being animated’ has a programmed or written default state. When I animate then, everything is progressive and linear, I can always get rid of those introductory keyframes afterwards, or return to that default state as a start to the next scene. I’m not a programmer but I don’t understand why you can’t have another state of marking as an example ‘Scene – Frame’ Theses could serve as default states and a captured end state that needs to be held. I think unity could capture the last position of every thing in entirety as a ‘scene – frame’ on the fly unless commanded otherwise or waiting for the next animation state.
    I may have missed your point but the idea makes sense in my head!!
    I love the fact you guys ask for our oinions, you must all be very patient.!!

  34. Richard Fine

    May 31, 2014 at 7:30 pm / 

    The biggest problem AFAICT is that I didn’t even know this behaviour was present – I was aware that parameters would return to default values if not animated by a clip, but not all curves. What default values get used? When and where are those defaults set?

    I think what I’d probably be inclined to do is something like: permit animation clips to include curves that have no keyframes in. If a curve has no keys, the property remains unchanged; but if there’s no curve at all, use the default value, and be very clear about what that value is / where it’s coming from.

  35. Pierre-Paul Giroux

    May 31, 2014 at 6:17 pm / 

    @MICHAEL: indeed, turning off the Animator to keep current values does sound hackish. This is why Im thinking of adding the option!

    @andy: Interessting, but this is certainly more AI related then Animation related :)

    @chris: you can always create Mecanim animationClip in code (in editor only tough)

    @galen. Yeah. I think that having the option not to force to default should fix a lot of the problems. About the events not fired, it you still get the problems in 4.5, please file me a bug!

    @laurent: If I recall correctly – I mostly worked on the HIK solver- Motionbuilder’s Story tool would force back to defaults values. While I think it makes sense in an authoring tool, its another story with a game engine. In anycase, if we have the option, you can have both world !

  36. Laurent

    May 31, 2014 at 10:16 am / 

    PPG, I think you worked at Kaydara, or Softimage, what was the default behavior of the sequencer in such case? It felt quite intuitive.

  37. Galen Ryder

    May 31, 2014 at 9:57 am / 

    I just recently spent a bunch of time creating animated UI using mecanim and ran into a lot of problems with the current system.

    I think having an option to not reset the property values to their default would save me a ton of time and be much more friendly for our artists. I had to work around a bunch of problems by using Animation Events to do stuff like change the active state of objects. I often had to animate the value of a property during animations just to keep it in the right place or set it to a position that was crucial for the next animation state, otherwise I would end up with some really funky interpolation. These workarounds kind of suck because it means I often had to change multiple animations when a UI layout changed, even through only 1 or 2 were crucial, so lots of room for human error.

    Determining how default values were set also took some detective work. Unless I am wrong the default values are set when the animator is activated. So if you animate something’s position from the left to the right. Turn the gameobject with the animator off. Turn it on again, The default value of that animated object’s position now starts on the right. So I had to create scripts that reset the position values OnDisable.

    I managed to get everything working in the end but ran into lots of other timing issues like Animation Events not always being triggered if they are on the first or last frames. Weird behaviours with empty nodes and transition time. Some of which I think were fixed with 4.5. Everything works and I can even play it at 16X speed to allow users to skip through animations but I think the workarounds made it a bit daunting for the artists to modify.

  38. Chris

    May 31, 2014 at 9:11 am / 

    Is it possible to generate Mecanim AnimationClips in code?

    It’s possible to generate just about any kind of AnimationCurve in Legacy; if the same is possible in Mecanim the most intuitive behaviour is probably to just have the default, and for advanced uses we’ll just generate our own clips?

  39. UNITYYYYYYYYYY plz plz plz

    May 31, 2014 at 2:39 am / 

    please unity update news daily plz plz plzzzzzzzz
    pleaseeeeeeeeeeeeeeeee i want to see news news news :D =)

  40. Andy

    May 31, 2014 at 1:48 am / 

    What can I say? I’ve tried transitioning into an animation walking using a humanoid that I setup to ‘glide’ along a NavMesh I baked in Unity Free 4.3 and NavMesh Agent and kept be told how easy it was and oh, I have no problem, and modified example code and nothing worked.

    What I’d like to see is the animation system set-up to be human friendly. By that I mean a horse has a set of behaviours and a human has a set of behaviours and I send environmental stimuli (e.g. puma is line of sight) and the horse, being a horse, typical bolts and runs while a human’s might be different depending on personality and tools available on sighting a puma.

    You can call resting the idle stimuli if you like.

    So environment says puma, horse says run. Very human like game programming.

  41. Adam Ormsby

    May 31, 2014 at 12:36 am / 

    Options are usually a good thing, and I’d love to see the option to hold onto property values. Though I’ve never run into a situation so far where I would need that option, it sounds like it could actually be pretty useful.

  42. Pierre-Paul Giroux

    May 30, 2014 at 11:31 pm / 

    @rune
    Louard has a good example of expected behaviour when transitionning into empty states. A similar example also came up many times with Sprites, where users would have expected the empty state to leave the sprite to its last value, but instead would return back to the default Sprite.

    Another example that I’ve seen is that let’s say at some point in game logic, you want to change the value of a property via script – scale for instance – of an object. If you have, a single animation in the controller that has scale animation, it will always return back to its default value. This makes it hard to debug and understand what is happening.

    As for poping during transitions, ive made a prototype where I record the values and use it as starting point. It seemed to work very well.

  43. Michael

    May 30, 2014 at 11:26 pm / 

    Yeah, that option – whether to change the value to default or keep the last values – would be awesome, since Animation and AnimationEvents do more than change a transformation… I personally use AnimationClips as “automation” to do stuff other than just move a GameObject. Now, when an animation ends and don’t want to do anything else but also keep the latest values, I have to turn off the Animator. But that’s a bad approach, right?

  44. Rune Skovbo Johansen

    May 30, 2014 at 11:09 pm / 

    > Our idea is to change the default behavior so that properties are not forced back to their default values when not animated.

    The legacy animation system worked the way you propose and it was a pain to work with. So much time was spend debugging weird poses that arose from “leftovers” from clips that had previously played.

    A question is also how you’re going to handle it when a transition is started to a state that controls a property that wasn’t previously controlled.
    - The legacy system would immediately snap to the value the new state set it to because no other clip contributed to the weighted average. This meant a lot of Unity games had characters popping into various poses.
    - An alternative approach would be to take a snapshot of the current value and then use that as the starting point for a cross fade. That would at least lead to less (or no) popping. It wouldn’t solve the problem of leftover values though.

    Can you tell a bit more about what made you consider changing the behavior and even going as far as making the proposed behavior the new default?

  45. Louard

    May 30, 2014 at 10:06 pm / 

    Not really a vote either way, just an anecdote. Just this week, we encountered a “bug” with an animation we produced because we had assumed that we could make an empty state that would cause the model to hold on the last frame of the previous state. It did not!

Comments are closed.