What is the Animator CrossFade "normalizedTransitionTime"?

What really is the "normalizedTransitionTime" parameter in CrossFade and CrossFadeInFixedTime?
Is it the exit time?


same question ...

Unity doc about Animator.CrossFade is unclear and confused ...

my guess:

Animator.CrossFade(int stateHashName, float normalizedTransitionDuration, int layer, float normalizedTimeOffset, float normalizedTransitionTime);

  • normalizedTransitionDuration : normalized transition duration refer to current state
  • normalizedTimeOffset : normalized transition offset refer to current state
  • normalizedTransitionTime: normalized transition offset refer to target state

I reported the issues with those documentation pages a few years ago and I'm entirely unsurprised to see that they have still done absolutely nothing about it.



1 Like


1 Like


hi, how can control TransitionTime? myskateboard

Define control. What are you trying to do?



1 Like

It's super clear! It's the time of the transition, but normalized! Duh!

This is what you get if you let Doxygen generate you documentation.

Look at these functions. they have two parameters:
normalizedTransitionDuration: The duration of the transition (normalized).
normalizedTransitionTime: The time of the transition (normalized).

I am not sure what the different between them.

Haha, this is just so typical for the Animator.

"Normalized time" should just mean the duration expressed as a value between 0 and 1 - 0 is the start, 1 is the end. We use that all the time in our own animation system - asking for the current normalized time of an animation is pretty common in order to use as input to lerp functions or whatever.

So normalized time offset for a cross fade makes a lot of sense - CrossFade with a .2 normalized duration would mean "the cross fade should take 20% of the duration of the animation to finish". Same for offset - how far into the animation do you want to crossfade?

The only problem is... which animation? Is the normalized duration expressed as a normalized part of the source animation, or the destination animation?

If you think about it, it can't really be the source animation, because Mecanim doesn't really have a concept of a source animation, or the "current animation" to blend from. What you're CrossFading from is the current blend of the animation graph, which can be any arbitrary blend of any number of animations. So the only sensible thing to use the normalized duration of is the destination state, because that's the only thing that's clearly defined!

So, hey, I understood how this works after thinking about it because I've built an animation system. That's not going to be the case for the average reader of the Animator docs!

@UnityChinny , Mecanim has been poorly documented for years. Every droplet of information about why something does what it does has required, if not a battle, then at least a skirmish with either bug reports or forum nagging before it's available.

So big questions going forwards is;
- Are you aware, internally, that the documentation is in fact lackluster?
- Do you know why it's like this? What went wrong over the years for the API docs to end up where it is?
- Are there plans in place for the new animation system to ensure that this doesn't happen again?


After some experiments, my conclusions are as follows:
"normalizedTransitionDuration" is the duration of the transition, based on current state length. In inspector window, it's "Transition Duration (%)".
"normalizedTimeOffset" is the transition target offset time, based on next state length. In inspector window, It's "Transition Offset".
"normalizedTransitionTime" is how much time has already passed of the transition, based on TransitionDuration. For example, normalizedTransitionTime = 0.3 means the transition is 30% complete in the first time.

Here's the full example:
stateA (total 2 second) has played 1s, when crossfade to stateB (total 3 second) is called, parameters are:
normalizedTransitionDuration = 0.5,
normalizedTimeOffset = 0.3,
normalizedTransitionTime = 0.2.

the transition total time is 1 second (2s * 0.5);
the transition real time is 0.8 second (1s * (1 - 0.2)), as it starts at 20% in progress;
during the transition,
stateA plays from 1s to 1.8s (1s + 0.8s), weight fade out from 80% to 0%;
stateB plays from 0.9s (3s * 0.3) to 1.7s (0.9s + 0.8s), weight fade in from 20% to 100%.
PS: timeOffset of stateB is not affected by normalizedTransitionTime, it doesn't start at 1.1s.


That all sounds reasonable, but I suspect the start time of stateB might also take into account the 0.2 normalizedTransitionTime to skip it even further ahead in time from the base normalizedTimeOffset rather than only affecting the weight. Otherwise the skipped weight wouldn’t match the usual time if that fade had played out normally.

Is there a single person that finds any usefulness to the transition duration being set in normalized time of the destination animation?

Ever since its inception it sounded like a bizarre decision, why would I want my Run to Jump transition to change duration because I added a couple of seconds of easing at the end of the Jump?

I had the same suspicion until I tested it, so I added the conclusion to “PS”. It doesn’t seem very reasonable, but it may be because otherwise user can hardly find proper parameters to crossfade to stateB at the start frame when normalizedTransitionTime > 0 (though it’s an unusual demand).
In fact, “auto skip” means it suggest (or restrict) me to fade the weight in a linear mode. If not “auto skip”, I can call CrossFade every frame to update the weight in whatever mode I want (it’s tricky, but effective).

Maybe It’s more convenient to use fixed time transition for Run to Jump transition if the Jump duration is volatile. But it’s really useful for Walk to Run transition to match left / right steps.

So the default is useful in one use case… cool.

But also, I’m not sure if I get the usecase. If walk and run are synced, what does it matter how long the crossfade time is? It will look reasonable regardless.