Question about the division of animations in the demo animator ('recoil' animations etc.)

stove

New member
Hi everyone,

I've been working on creating my own animations and UCC-friendly animator. I've mostly gotten things set up and working on the animator side of things, but I'm realizing I have some bigger picture questions about why the demo animations are set up the way they are. Specifically, I'm wondering why, in many of the many of the more complicated substate machines involving full body weapon uses, a single action gets broken into two: e.g. 'Attack 2 from idle' leads to 'Attack 2 recoil to idle' as opposed to just having 'Attack 2 from idle' go back to the same idle pose on the final frame. It leads to an enormous increase in complexity for the animator substates, and it's clear that Unity's UX struggles to keep up with the sheer quantity of transitions in some of the substates (It turns into spaghetti).

Now, I assumed that this had to do with not wanting to trust Unity's animator to handle the timing of blended animations-- but is there more to it than that? Should I set up my own custom animations with these kinds of 'breakpoints' in mind, at least in some cases? What would I lose if my own attack animation is a longer there-and-back-again loop?

(Apologies if this was explained somewhere, or if this is more a general Unity question: I watched all the videos but tend to focus on the specifics of getting things to work as opposed to the reason for these kinds of decisions)
 
I assumed that this had to do with not wanting to trust Unity's animator to handle the timing of blended animations-
That's correct - this is to give more precise control over the transition between the two states rather than relying on the blend tree transition.

Should I set up my own custom animations with these kinds of 'breakpoints' in mind, at least in some cases? What would I lose if my own attack animation is a longer there-and-back-again loop?
I think it's something that you should have in the back of your mind as another way to accomplish the task, but I wouldn't rely on it unless you are tuning your project and notice that you want a bit more control over it.

From the controller side of things all it cares about are:
- You have the correct animator parameters
- If you are relying on an event (such as the jump event), then that event should be sent from the animator.

It does not require you to structure your animator in any specific way, and choosing not to transition like we did is a perfectly valid decision.
 
Top