The documentation recommends starting from scratch with a brand new animator controller, adding only the parts you need, but aside from perhaps wanting to prune things a bit for purposes of clarity, is there anything *wrong* or perhaps *nonoptimal* if you choose to just reuse the demo animator controller and associated animations?
Is there an advantage to replacing the animator controller?
- Thread starter lynnpye
- Start date
The demo animator controller covers a lot of use cases that you likely won't have in your own game. For example, in the demo you can throw a grenade at any point or you can equip the grenade and then throw. Normally you'd choose one or the other. It also includes the states for the abilities that you may not be using (such as ride) so you are getting a much bigger animator controller than is optimal if you just copy the existing animator controller.
digitalOctopus
Member
I too had this same question. For a few months I didn't bother, and figured that a big controller with too many use cases was better than spending time rebuilding what was already provided. For whatever reason one night, I decided to build my own, and to not stop working on it til I at least had a character that could run and jump.
The learning process of figuring out how the transitions work and how the animation event triggers work, in addition to reading up on the ability code, really gave me a better understanding of the tools. Now I have some custom abilities that use custom animations and custom events, which AREN'T provided in the demo controller. Worth the effort if you want a random guy's opinion.
Actually, this learning process led me down a really deep rabbit hole, and I wrote a script which takes my rigged character, builds it in UCC using my custom controller, runs it through FinalIK to set up ragdoll, applies some other assets, and lets me go through the whole 15 minute process in one click.
The learning process of figuring out how the transitions work and how the animation event triggers work, in addition to reading up on the ability code, really gave me a better understanding of the tools. Now I have some custom abilities that use custom animations and custom events, which AREN'T provided in the demo controller. Worth the effort if you want a random guy's opinion.
Actually, this learning process led me down a really deep rabbit hole, and I wrote a script which takes my rigged character, builds it in UCC using my custom controller, runs it through FinalIK to set up ragdoll, applies some other assets, and lets me go through the whole 15 minute process in one click.
I appreciate the replies and they do give some insight regarding benefits of rolling your own with respect to the learning exercise. Having gone through that myself, I agree, it's been useful to understand more of what's going on.
But I don't understand the question regarding "optimization". That is, what is "non-optimal" about an overly large animator controller? Does it execute more slowly? Require more cycles to process a given animation or transition due to considering a larger set of possible states? Is it a size optimization issue?
If anything, I would expect it to be performance related, i.e. needing more cycles to consider that *this* ID is 12 and this substate ID is 42, so perform this animation, etc. Yet I would expect that would not actually result in any significant difference in terms of performance.
I haven't tried profiling to find out but... again... I don't see spelled out *what* exactly is suboptimal about reusing the existing demo animator controller.
So... assuming that I *have* gone through the exercise of creating my own, learned what I wanted, and *still* decide to switch to reusing (and of course, further modifying a copy of) the demo animator controller... then what am I losing out on or doing to my game that is *bad*?
Because as far as I can tell... right now the answer is... not much.
But I don't understand the question regarding "optimization". That is, what is "non-optimal" about an overly large animator controller? Does it execute more slowly? Require more cycles to process a given animation or transition due to considering a larger set of possible states? Is it a size optimization issue?
If anything, I would expect it to be performance related, i.e. needing more cycles to consider that *this* ID is 12 and this substate ID is 42, so perform this animation, etc. Yet I would expect that would not actually result in any significant difference in terms of performance.
I haven't tried profiling to find out but... again... I don't see spelled out *what* exactly is suboptimal about reusing the existing demo animator controller.
So... assuming that I *have* gone through the exercise of creating my own, learned what I wanted, and *still* decide to switch to reusing (and of course, further modifying a copy of) the demo animator controller... then what am I losing out on or doing to my game that is *bad*?
Because as far as I can tell... right now the answer is... not much.
digitalOctopus
Member
I don't imagine you're losing more than a little runtime memory, which is probably fine if you're not on mobile. I suspect the demo controller is part of the asset, partially as a learning tool, but also so people can repurpose it if they so choose. Would be interested to learn if I'm wrong though.
For what it's worth, I stumbled upon this post, which points out a few things about animators and optimization:
https://forum.unity.com/threads/per...imators-vs-single-multilayer-animator.428234/
In particular (at least what I gleaned from reading):
- Fewer animators controlling multiple animations is better than more animators controlling fewer animations (both for organization and due to memory overhead per animator)
- Inclusion of additional states does actually come at a cost because the additional paths have to be checked (what I suspected but wasn't sure of, but the point is it is a noticeable difference)
- Animation blending also comes at a cost, be careful not to let your blends take up too many cycles
https://forum.unity.com/threads/per...imators-vs-single-multilayer-animator.428234/
In particular (at least what I gleaned from reading):
- Fewer animators controlling multiple animations is better than more animators controlling fewer animations (both for organization and due to memory overhead per animator)
- Inclusion of additional states does actually come at a cost because the additional paths have to be checked (what I suspected but wasn't sure of, but the point is it is a noticeable difference)
- Animation blending also comes at a cost, be careful not to let your blends take up too many cycles