Write Defaults Confusion / Bug

Just trying to get something cleared up that doesn't seem to be working.

Our team has found that when ever we animate something, lets say a simple button, we must animate every property in every state if that property is to change in any state. For example. Let's say we have a simple controller for a custom button with these states:

Normal

Pressed


Let's say that we animate the color of the Image to tint the button in the pressed state. We are finding that unless we animate the Image color in the Normal state back to the original color, the button will often get stuck in the tinted state and start behaving incorrectly. This seems to apply to animations throughout our project. In more complex animations like our main Beast characters this means that our artists must animate every single property in every single state and it becomes quickly unmanageable. We've read multiple times about the 'Write Defaults' property that exists on each animation state, but it doesn't seem to behave as defined by Unity. Either we're not understanding the property or it simple isn't working.

Here are some quotes I found about how it is supposed to work:

Am I doing something wrong? I would expect that with the 'Write Defaults' option checked, when we return to the Normal state the color of the button would return to the untinted normal Color without the need to animate a Color keyframe. Any clarity here would help.

Thanks!

 

I'm surprised, no one else is having this issue? Specifically I'm referring to the 'Write Defaults' option in the inspector when selecting an animation state within a controller:



I expect with this option selected that given 2 animated states, A and B, if I animate a property (like Color) in state B, but DO NOT animate the same property in state A, that when returning to A the default value for color would be used. This unfortunately is not the case, and requires we animated the color property in the A state as well to ensure it returns to normal.

This creates multiple times the work and is super-error prone considering that if you miss a single property in a single state, the animation can mess up at runtime.

Is Write Defaults working for anyone? Am I misunderstanding its use? Or is there an obvious workaround for this inconvenience that I'm missing? Any help here would save our animators a ton of time.

Thanks

 

I just enabled Write Defaults on all our animations in my current project and it appears to be working correctly. I'm using it to solve the exact problem you describe. Our UI artist is mixing and matching animations on UI objects, so we may scale something in to show it, then alpha fade it out to hide it. Without Write Defaults, the second time an object was shown it would still have 0 alpha from the previous fade and would be invisible. With it enabled the alpha gets instantly reset to 1 as expected.

So I'd say the documentation and your description appear correct. And at least in 5.3.2p2 it appears to be working properly.

Going from DavidGeoffroy's response, perhaps your animator controller is picking up the wrong default value? Is the object in a weird state at init time?

 

I'm having exactly the same issue: when I deactivate an animated gameObject, and I reactivate it again, then default values are changed. Did you managed how to solve it?

 

I submitted a bug for this problem a year ago (Case 694834). It got closed as "won't fix". So there is no way to solve it.

 

That's a terrible bug... I don't understand why Unity developers won't fix it

 

Hi @DavidGeoffroy. I've reproduced the issue using your project (cubePositionAndColor.unitypackage). Execute it, and when the cube is at the top position (and green), deactivate it in the editor, then activate it again, and you will see that it won't go to the bottom anymore. Is this the correct behavior?

 

Any news regarding this topic?

Based on DavidGeoffroy explanation, I assume that when the game object is deactivated, and reactivated, then the animator read all the current values, and saves them as default values. I think this behavior is not correct, because it will cause unpredictable situations in animations. Is there any way to change this behavior?

 

I agree that the Animator recalculating defaults every time it is enabled is unintuitive and undesirable. I'd much rather have it either calculate defaults on the first enable and then never again or have control over when it recalculates.

It would also be helpful if the intended behavior was more clearly documented in the Scripting API and Manual. I find the existing documentation too vague to be helpful and resorted to searching for random forum posts to understand it. David's response in this thread was one of the most helpful.

 

I ended up creating a generic script that saves all values in "Awake", and restores them in "onDisable". Attaching it to my objects solves the problem. I feel it's a bit "tricky", but it just works.

 

Anything new on this topic? I believe I am experiencing the same behaviour.

 

Just tried this on the OnDisable function for a mono behavior in the same game object and unfortunately doesn't work. I added logs to check that the transition happens and it it seems like the animator goes to the right state but it never gets updated (I added an internal StateMachineBehaviour to check if update and state enter get called and they don't) .

This is unfortunately a big deal as we use object pools to recycle some objects. So being able to reset to the right defaults is important for when reusing those objects.

 

So after playing with this for a while I got a solution that seems to be working based on the original solution proposed 2 posts above:

Code (CSharp):

1. public void ReturnRewardItem(Item item)
2.     {
3.         item.transform.SetParent(null, false);
4.         Animator itemAnimator = item.GetComponent<Animator>();
5.         itemAnimator.CrossFade("Base Layer.Default", 0f);
6.         itemAnimator.Update(0f);
7.  
8.         StartCoroutine(ReturnItemCoroutine(item));
9.     }
10.  
11.     private IEnumerator ReturnItemCoroutine(Item item)
12.     {
13.         Animator itemAnimator = item.GetComponent<Animator>();
14.         int hashName = Animator.StringToHash("Base Layer.Default");
15.  
16.         do
17.         {
18.             yield return new WaitForEndOfFrame();
19.         }
20.         while(itemAnimator.GetCurrentAnimatorStateInfo(0).fullPathHash != hashName);
21.  
22.         item.gameObject.SetActive(false);
23.         itemPool.Return(Item);
24.  
25.         yield break;
26.     }

What seems to happen as far as I can tell is that we need to wait a frame to deactivate the object, so I don't think the while loop is that necessary (but have not tested without it).

Anyhow I will still create a custom scene with this and a bug if I can get

 

This solution is problematic. It requires you to be aware of the possibility an Animator existing anywhere in an object hierarchy. If I disable a UI menu object, I now have to think about whether there are any Animators on it and I have to try to disable the entire UI around this one problematic object. And as soon as someone adds a new Animator, things are broken or I have to go back and spend time supporting this new thing.

Or, I could try to implement a general approach. Any object that uses an Animator can be registered with some manager. Maybe I use a helper script. Whenever a compound UI object is going to be disabled this manager can kick in and make sure it resets the object. Now programmers have to remember to talk to this manager, designers need to remember a helper script, and I have all this infrastructure to work around a bad design.

This suffers from the similar problems as above, with the added catch that updating dozens of animators might cause a hiccup. My original solution was almost exactly this. I remember that I had to call Update twice for it to work for reasons unknown. I also remember that this approach randomly stopped working shortly after I implemented it for no reason I was able to discern. I got fed up and ended up just manually resetting all animated values (luckily I know they all start at zero so I don't have to make it even klugdier and remember the initial values).

You're assuming it's reasonable to have to micromanage dozens of Animators in a hierarchy because I want to disable the parent object.

I have a difficult time accepting that this can't/won't be completely solved in a clean way. Even just optionally applying defaults when the Animator is disabled would be a vastly better solution than the above.

 

This issue is indeed pretty disturbing. I had some chance with the IsInTransition boolean in Animator when pooling my objects. It is inspired by the solutions above but with a more "generic" touch IMHO.

What it does :
- If there is not an animator, Pool object simply
- If GO has an animator wait for the animator to finish transition for all its layers.
- Moreover if one of the layers has a ABaseStateBehaviour.RESET_STATE_NAME then trigger the ABaseStateBehaviour.RESET_DEFAULT_TRIGGER in order to transition to default state. (not mandatory)

Code (CSharp):

1.  
2. public void Store()
3.    {
4.        SendResetAction();
5.  
6.         //store or destroy
7.         if ( m_Pool && ActivatePooling )
8.         {
9.             StartCoroutine(PoolStoreCoroutine());
10.         }
11.         else
12.         {
13.             Destroy(gameObject);
14.         }
15.     }
16.  
17.     public void SendResetAction()
18.     {
19.         SendEvent<IHasOnResetAction>(x => x.ResetAction());
20.     }
21.  
22.     public IEnumerator PoolStoreCoroutine()
23.     {
24.         Animator itemAnimator = GetComponent<Animator>();
25.         if (itemAnimator != null)
26.         {
27.             var l_NLayer = itemAnimator.layerCount;
28.             var l_ResetStateHash = Animator.StringToHash(ABaseStateBehaviour.RESET_STATE_NAME);
29.             var l_HasReset = false;
30.             for (int i = 0; i < l_NLayer; i++)
31.             {
32.                 if (itemAnimator.HasState(i, l_ResetStateHash))
33.                 {
34.                     l_HasReset = true;
35.                 }
36.            
37.             }
38.  
39.             if( l_HasReset ) itemAnimator.SetTrigger(ABaseStateBehaviour.RESET_DEFAULT_TRIGGER);
40.  
41.             for (int i = 0; i < l_NLayer; i++)
42.             {
43.                 do
44.                 {
45.                     yield return new WaitForEndOfFrame();
46.                 } while (itemAnimator.IsInTransition(i) );
47.             }
48.         }
49.    
50.         m_Pool.Store(this);
51.    
52.     }

 

It seems like it does not working with unity 2017.2, someone made it work with an older version (I tried with more than 0f for the update call)

@DavidGeoffroy

 

Components have to deallocate everything when the GameObject is disabled? Sounds like a serious design flaw in the engine but it doesn't explain why there is no reasonable workaround for this particular problem or why you guys think that completely trashing the animation states on disable (with no way of ever reseting them again) is an acceptable behaviour.

No the problem is not the insignificant amount of memory that would take in most cases, the problem is that it's a hacky inelegant solution where we need to go through the whole hierarchy (transform subtree) of game objects and disable all the components on each of them while making a dangerous assumption that there is no other reason any of them need to be disabled in the first place.

Honestly, this would be a wonderful solution... If it worked... Which apparently it doesn't.

Yeah you guys always have something in the plans. Too bad we have to make games now and not in the year 2050.
I swear, working with Unity is like a death by a thousand cuts. Every single thing is just barely usable enough to make you think you can manage it, but by the time you realise all the deep design flaws it has, it's too late to go back and your project is already just a collection of ugly unintuitive workarounds.

 

I could really use a generic solution to this problem. I'm trying a technique where I disable the parent of a lot of animators, and restoring their state individually is not going to scale well.

Is it possible to just get a function like, animator.ResetToDefaultValues() ?

 

When trying to think of a generic solution, I thought about using UnityEditor.AnimaitionUtility to find all the bindings used by animator and store them in a component from the editor. Then, in the runtime, use reflection to find, store, and update all the default values.

I got this working to a point, but I couldn't seem to get access to the private members m_LocalScale / localEulerAnglesRaw on RectTransform with reflection. Is this approach possible?

This approach also seems pretty hacky, but I'm still curious if this could work.

 

For those interested, I was able to write a solution for this using reflection - like I described above. It's not a pretty solution, but if I don't have any further problems with it, maybe I'll clean up the code and share it.

Also, I'm not sure how high the runtime cost is for this. I assume the animation system in Unity must also access these variables using some sort of reflection?

 

I stumbled upon this issue while debugging why my animations were doing weird stuff. I have to second the points made above. For now I am settling for resetting the properties I know will get messed up in OnDisable, but all of these workarounds are quite hacky and often difficult to maintain.

 

Yeah this worked in 2017.2.1 but not in 2017.2.2. It's intensely frustrating. Has anyone got a reasonable workaround? Or can tell me it's better in 2018?

 

Anyone having this issue should check out my Animancer plugin. One of my users was having trouble with Mecanim leaving objects in their partially animated state when deactivating them for object pooling and found that my plugin is able to work around the problem if you stop all animations then call Evaluate before deactivating the GameObject (it must be before the SetActive(false) call as trying to do it in my script's OnDisable method has no effect).

I'm not entirely sure if this is directly applicable to OP's situation, but I'd be interested to hear more feedback from anyone who tries it.

 

This is not the way write defaults should work. The default joint values should be take defined by the values in the animation RIG not individual animation clips!
I was an engine / tool programmer with Sony for 17 years, and worked closely with the low level animation engine shared by both Sony and Naughty Dog, and this is the way it is done. I've encountered really strange problems when joints that aren't animated in the hierarchy, and this explains why. This should be an easy fix really, and it sounds like it would even simplify your existing system.

 

What do you mean by call "Evaluate"? Where and what is this call?

 

One gazillion times this ^^^

 

Unity, make an effort to fix this sort of nonsense. Or find and publish elegant workarounds in such a way that they're easy to find, well explained and kept up to date.

This kind of farcical uselessness in the face of simple problems is just flat out atrocious.

 

The AnimancerController component in Animancer has a method called Evaluate which applies the current state of the Playable Graph to the actual objects being animated.

 

I've had a complete gut full of Unity's Animation System for today, and the last three, actually. Enough. Is Enough.

The final straw... I updated today, to the latest, I was updates behind the latest 2018.1 version.

And, joy of joys, now it crashes when I rollover a state in the state editor. Never seen that before.

Please, tell me more about your solution, good sir!

 

The easiest way to understand it is probably just to download the Lite version from the Asset Store and play around a bit.

Basically, instead of creating an AnimatorController asset like you normally would for Mecanim you add an AnimancerController component to the same object as the Animator, then you control everything through that component. When you want to play an animation, you literally just get a reference to it and call AnimancerController.Play(AnimationClip) on it.

If you have any further questions I'd be happy to answer them via the email address listed on the store page and in the manual so we don't clutter up this thread.

 

with all due respect, this is wrong:

There is no other industry in the world that gets away with even thinking like this.

Then, consider the situation I (and most others coming to your product) will have been in, that lead us to consider your product: frustration after having tried a million other dalliances and deviations in the hope we'd wrangle Animator, Animations and Timelines into doing things one might normally expect to just work.

That time can't be gotten back, and leads to a build up of fury that is compounded by two things:
1. Unity indifference and borderline disdain for its users, in their complete failure to signpost this recurring nightmare that each new user has
2. The discovery that this is an ongoing problem, with no apparent solutions pending or seriously being considered

-------------

Now, about you, and your asset/product. I don't know you. Why should I believe you, that it fixes what nobody else's seemed able to fix, let alone Unity themselves?

Why should I trust you with my time if you can't trouble yourself to explain the benefits, killer features and end user experience of your product. And it is a product.

Anyone coming to this end of this problem is likely like me, exhausted, already.

It is again, with all due respect, on you to convince me that I should spend yet more time on you, a relative unknown, to solve these problems in a largely unknown, largely undocumented manner in which you can't do anything better than say: "try it for yourself... burn more time, it costs me nothing to have your burn your time."

Thanks. No. Unity has spent all my spare time.

 

What? I'm not selling snake oil and trying to scam you out of your money, I'm giving you access to a free trial and allowing you to test it out. Have you never seen a product with a free trial before?

You don't need to believe me. The Lite version is totally free for you try out. I can't possibly know what exact problem you're having so how could you possibly expect me to convince you 100% that I can fix it for you? Several users have politely contacted me about problems that would only be addressed by features in the Pro version and I was happy to demonstrate my plugin for them with the result being that I had to recommend some of them not use my plugin in the end.

1. I did just explain the main killer feature of my product.
2. All of the other features are already explained on the store page, and if that's not enough detail for you then you can download the Lite version and read the 14 page user manual.

It's actually up to you to investigate potential solutions to your own problems. If you've already decided that you're not going to put any more effort against this problem then no amount of effort on my part would be able to convince you otherwise.

 

You've missed the point.

TIME is the cost.

 

No, you've missed the point. It's your project which you are spending your time developing. Some of that time you spend is going to be on solving problems such as this one. I don't actually know what your problem is, so it's physically impossible for me to honestly tell you if my product can solve it for you.

I've given a concise explanation of my plugin, the description on the asset store, a detailed user manual, and a free trial. What more do you think you're entitled to getting for free from a stranger on the internet?

 

You're getting a bit off topic, and promoting your assets in other threads is slightly tact-less.

But with that said:

You shouldn't, you should get the Lite version and see for yourself. It's called evaluating a piece of software to see if it suits your needs. Even if he gave a super amazing pitch for his software, that's still a pitch, it may or may not suit your needs. Whether or not SilentSin is a good salesman has little to do with how good or not his software is for you.



Can we get back on topic about how much Mecanim sucks now?

 

Telling me (and you and everyone else suffering from Mecanim) about the methodologies, practices and paradigms utilised in a piece of software designed to thwart its goal of ruining our lives, that's not selling. That's sharing, caring and communicating.

To then explain, detail and articulate the reasonings, discoveries and insights (and perhaps even wisdom) that lead to its creation, also not selling.

Persuading us he's sincere in his desire to make the world a better place by supplanting the need to use Mecanim, also not selling. And not unwelcome.

But they'd all make me more likely to spend the time to further investigate.

An arrogant dismissal of the time it takes to check the pedigree of his software, that's not welcome, nor welcoming.

As it is, if he's not willing to stand behind his endeavours more thoroughly than "try it and see", then I'm not willing to spend the time.

Assessing the integrity of a product by the manner in which its founder/creator appears to believe in it (or otherwise) is also a thing, and much faster than trying every single thing on the market. To paraphrase you, "it's called evaluating the creator", or words to that effect.

 

I didn't ask you to solve my problems.

I asked you to tell me about your product.

You don't want to.

Fine. I'm moving on.

 

Go back and read my first post in this thread. I don't "believe in" my plugin as a solution to this problem because I've never had this problem and I explicitly stated that I don't know if it is applicable, I only mentioned it because one of my users said it helped them with a similar problem. If that was your criteria for whether or not you'll explore a particular option then you shouldn't have responded in the first place.

I did tell you about my product. I gave you a summary, the store page tells you more, the user manual tells you even more, and I offered to answer any other questions you might have. Are you expecting me to copy and paste my full user manual into a post here for you? That's a serious question, I honestly have no idea what you're expecting here.

If you don't give me any details about your problem, how can I possibly do any more than suggest a possible solution and say "try it and see"?

 

Anyone find a solution yet? im on Unity 2018.1.3f and im starting to think that switching to Unreal engine 4 will be the only solution which is ridiculous that after all this years Unity hasnt fixed this. So it is literally impossible to pool objects with animators attached

 

Word of warning: 2018.1.5f -- I updated to this during this battle with these problems, only to find that it crashes a LOT, multiple times in an afternoon, just when I'm rolling over interface elements, including aspects of the state machine in Animator.

I've had to further upgrade. to the current 2018.2.xxx to get some semblance of workability back.

 

Sorry, forgot the main point: other than the inability to get things with the states working the way I'd want/expect or can be certain of, the version you're on : 2018.1.3f was relatively stable. It certainly never crashed multiple times in an afternoon like the 'update' did.

So far, no problems with 2018.2.0b8 or 0b9.... so far.

 

This is EXACTLY the problem I'm up against. Tried different pooling systems and other tricks, wasted days researching and experimenting. No dice.

I'm rolling back all I was doing in Animators, Animations and Timelines to particle systems, but... I'm lucky... was only working on visual and audio effects. I can farm off sounds to a sound manager and most of the effects I can get "near enough" with particles.

But, if you're working with imported animations and more complexity than my simple S***... yeah... I'd be taking a good long look at Unreal. A friend of mine is an expert in both, and other game engines and animations system creation, and he's made a strong case for Unreal being best in class, and an inspiration. I don't need all that extra weight, just making a simple 2.5D game. But if you're onto something bigger...

Baffles me that even my simple stuff hits these kinds of roadblocks.

 

Here is a solution that worked for me on Unity 5.x:

1. Create an Empty State "New State" or whatever.
2. Make sure the "Write Defaults" is on.
3. Use this when you want to disable the GO (anim is the Animator):
   
   Code (CSharp):

   1. anim.CrossFade("New State", 0f);
   2. anim.Update(0f);
   3. anim.Update(0f);
   4. gameObject.SetActive(false);

NB:

1. WaitForEndOfFrame seem to have no effect at all, it's anim.Update(0f) that does the trick.
2. If this solution doesn't work for you, try to call anim.Update(0f) 3 or more times.

 

I've resorted to using the Animation Component and scripts to activate and change animations. Works, but I had to do a lot of trial and error to find how to make it work, as the docs are marked "legacy" and ancient.

 

Hey, just peeking at this old thread again. I've since solved my issues by writing a messy behaviour called AnimatorStateRestorer. However, since then and now, Animator.keepAnimatorControllerStateOnDisable has been released with 2018.1. I haven't tested it yet (since my own solution has been working) but the documentation for it is vague. Does this maintain play time, state machine state, default values, and animation parameters?

 

I did a quick test in Unity 2018.1.9f2...

No, Animator.keepAnimatorControllerStateOnDisable does not save the default values. All the other state is saved perfectly though. This is unfortunate because the default values are the trickiest part to save!

I'm curious, why weren't the default values also saved with this setting? Was this an oversight or a deliberate design choice? It'd be nice to provide an option to save the default values, or at the very least, expose an API for them so we can do it ourselves more easily.

 

Thank you! Valuable information that saves me (and I hope others) much time.

I've moved almost everything to Animation (legacy) Components instead of Animator Controllers, and things like this keep me staying in my simplistic mode of doing things.