I would like to mention that the docs say the default sorting order of AnimationPlayableOutputs is 100. But it seems they are not including the Animator’s outputs (found in animator.playableGraph) in that statement, as I found them to be initialized with a sorting order of 65535 (ushort.MaxValue).
Is this intentional? If so, would the docs be able to be updated to include that information? Thanks 
The default sorting order upon creation is 100.
The animator configures its own internal AnimationPlayableOutput (for the built-in AnimatorController) to a different value. But this information isn’t really relevant to the AnimationPlayableOutput itself, it’s an implementation detail of the Animator.
Ahh gotcha, thanks! Is it possible to add this to the documentation? This actually made a huge difference to my game, allowing me to animate before and after the Animator does its thing
For more info:
I had custom AnimationClipPlayables to animate any animation clip, for my RPG’s skill system. Some of those clips were animating properties that the Animator doesn’t animate, so there were big issues with blending into the clips, since values had no other value to interpolate with. Thus, I needed to use AnimationScriptPlayables to write custom default values before the Animator (which required animation streams, so these values could be blended with the RPG skills’ AnimationClipPlayables), and then play the custom clips after both my AnimationScriptPlayables, and the Animator.
I’m very happy that you were able to achieve what you needed, but changing the evaluation order of the built-in AnimatorController graph is more an unforeseen side effect than a supported feature.
The order of evaluation of the built-in AnimatorController graph is -1, and we’ve limited the external API to ushort values so that the built-in graph always executes before user-supplied graphs. We had forgotten that the built-in graph was accessible from the Animator, and that it was therefore possible to change the execution order.
The Animator, Timeline and AnimationRigging package workflows rely on the assumption that the built-in controller runs first, and they might break in subtle and unforeseen ways if that doesn’t hold true. I don’t think we necessarily need to close the Animator.playableGraph loophole, but we also don’t want to publicize this widely, because that path is largely untested and it’s not one we plan to invest in to officially support.
The preferred solution is to build a graph with an AnimatorControllerPlayable in it, rather than changing the evaluation order of the built-in one. This should let you get exactly the same result, and it’s a path we’ve already invested time to support and test.
If you decide to try out the path I have suggested and find that you cannot achieve the same thing as changing the execution order of the built-in graph, please mention it.
Ohh wow, that’s intense ;)! I’m very grateful you mentioned all of that, and ahhhhhh… I get it now, the point of making another AnimatorControllerPlayable in our own graphs… clever!
I will definitely give it a go with my system! My sister and I are approaching a showcasing event October 12-13, so I’m not sure I’ll be able to get in this research time before then, but I’ll definitely give you an update soon when I get to it!
Happy to help.
Good luck in your showcase, and thank you for raising this point, we had completely missed that it was possible
@DavidGeoffroy Ohh… I see. So my next questions are:
Does building a 2nd graph (since animator.playableGraph would be the 1st graph) mean that the entire internal Unity animation update for that AnimatorController gets executed twice? Because if so, that’d be really bad for performance I think!
So if I want to be able to run some AnimationClipPlayables, AnimationScriptPlayables, etc. BEFORE and AFTER the AnimatorController, I’d need to create 3 AnimationPlayableOutputs (each with their own sorting order, say 90, 100, and 110 for example), and use the 1st and 3rd of those AnimationPlayableOutputs for my “BEFORE” and “AFTER” stuff?