Animation Status Update (Q2 2022)

Unity Engine
,
1

DOTS and Animation

  • If you have not seen it, check out the latest announcement around DOTS and Entities
  • So related to that, here is an update on the current state of DOTS and Unity Animation package (com.unity.animation)
  • DOTS animation is still under development. We have not released a package since 0.9.0-preview.6, though it is still available for use. However it is not compatible with the latest Entities 0.50 release (Unity 2020 LTS) due to dependencies on newer, unreleased technologies.
  • Entities 1.0 will be addressing some critical DOTS needs, and at the same time we have made some forward looking, and fundamental changes to the core of the animation engine and its tools. This means we have significantly diverged from the old experimental package. Until we are able to complete the new work, we will not be able to update the old package to be compatible with Entities 0.50, 0.51, or 1.0. The new animation system will be built using Entities 1.0, but won’t be ready for release at the same time as the Entities 1.0 package.
  • An all new experimental animation package will be ready for feedback some time after the Entities 1.0 release.
  • If you need to use Entities 1.0 when it is released, we recommend using Mecanim (classic Animator) for animation.

Animation progress, and your feedback

  • We are making steady progress on a number of animation fronts, from building on the new DOTS architecture, to having working prototypes as well as finishing some new functional features.
  • We have heard from many of you in different forms already, and are tackling many areas at once, which is a considerable undertaking. So to help us better focus and understand your priorities, as well as deliver a comprehensive feature set in a timely manner, we would love to hear even more from you. Check out the updated Under Consideration section in the Roadmap portal, and let us know your priorities.
  • Your feedback will go directly to me, and I will read and log every one of them!
  • We always appreciate a simple +1, but if you have the time to give us any extra context, that would be most welcome.
  • While we still do not have a concrete date for when we will get the new package released, your feedback and votes will go a long way to our focusing on what is absolutely needed.
  • Until then, we are continually working on fixing existing mecanim issues, and back porting where possible, and have addressed nearly 150 since my last post.

Important future consideration

  • While DOTS and Entities offer a very powerful set of tools to build games, we believe that there should be a way to accommodate whichever workflows you are most comfortable with.
  • We don’t want DOTS animation to be an all or nothing proposition, therefore we are investing in a hybrid mode, which will work with GameObjects and monobehavior, but will utilize DOTS power under the hood - wherever possible.

Gigaya and dogfooding

  • At GDC we showed a living game sample that the Unity team created and powered with existing Unity tech. It was fun to play, a good exercise in dogfooding, and helped many teams including animation. Check out more information here https://unity.com/demos/gigaya
  • As Gigaya evolves, it will continue to help us get ahead of new issues and workflows, before we release the new experimental animation package.
21 Likes
2

This is interesting to us!

We haven’t been looking at the DOTS stuff you have been using simply because we’re not interested in DOTS at this stage. A mode where Unity employees have to suffer through the abstraction olympics that is DOTS so we can get performant stuff without having to bother would be cool.

But, it would only be cool if the interface we work with is good. And, well, that means not repeating all the mistakes that makes the Animator such an utter pain. So, when you are setting out to build new systems, please take the time to ask the community about what needs to be kept and what needs to be thrown out, because oh boy the Animator is not good.

6 Likes
3

Unfortunately, reading the under consideration stuff on the roadmap, it gives me the impression that this realization is not shared by the animation devs…

4

Thank you both for the feedback.
The Animator is indeed rather old now, and we are definitely aware of where it did well, but also its limitations after such a long time.

3 Likes
5

Thanks for the heads up, that’s really helpful.

1 Like
6

I actually didn’t expect animation being the first optimization issue to deal with, while searching i found about animation instancing : https://blog.unity.com/technology/animation-instancing-instancing-for-skinnedmeshrenderer, is there any hope to see a more friendly implementation of this ? What’s the most popular asset on the asset store to deal with animation fps issue?

7

Probably baking mesh animations to textures, which is out of scope of this thread (please make a new thread if so). This one is specifically DOTS.

8

Hey, just a quick feedback …

I find Kinematica Motion Matching as -Critical-, as it’s next-gen Animation System the complies with the next-gen future of coding that’s DOTS. Unity lacks such a huge feature & is stuck in a nightmare solution that’s mecanim. 1+

The same applies to Ziva Facial Animation -Critical-, Unity should provide both the easy, and the complex facial animation, to harness the true power of its acquisition. Unity needs such a solution to advance in Animation & Competition, and to provide users with a variety of options for their workflow. 1+

  • And I also suggest: Animation Graphs should expose how the logic structure behind the nodes are done in code, that will (including but not limited to):

  • Allow artists’ process for learning code easier in general

  • Makes debugging simpler & more convenient

Remember: Make solutions comply with K.I.S.S. Simplicity + Robustness = Win-Win situation for Devs & Artists.

3 Likes
9

it would be helpful if you’d mention which are the limitations of mecanim you see

imho

  • humanoid rig would need 3 spine bones instead of 2
  • the root position being projected from hip has problematic use cases
    in some cases the root position is calculated wrong when transition happens (root offset being defined from start of animation, not blend start, probably is the cause of misplacement) this occurs with CrossFade, not sure if it comes up with state transitions
1 Like
10

This thread should square you away. Let’s not waste this thread and repeat those already discussed topics over here, and leave this thread only for DOTS related Animation stuff.

11

it won’t have humanoid rig, root position or crossfade?

12

I’m finding the Under Construction section highly discouraging.

Having so much focus on external stuff, fluff if I may say, while we don’t even have a wworking low-level core makes me think that Unity Animation is severely lacking a direction.

I absolutely support @ on his K.I.S.S. Simplicity point. After we have the strong workflow related to low-level animation stuff, set of simple and easy to use libraries, that solve the animation heavy lifting, only then we should talk about amination graphs, motion matching, etc.

I’m not even talking about the pathfinding and 3d character. Albeit I agree those components to be important, and used in almost any project, I have no idea why are they on a table for animation team.

We all know what happens when someone is trying to achieve everything, and I would really love Unity Animation team to succed and bring us a reliable, robust and scalable animation engine.

1 Like
13

I’ve had many sad trials with the Animator in the past few years, so finding this thread is pretty uplifting. I’m going to describe some feedback on improvements I wish to see of all scales and sizes - I hope they’re helpful, if even a little.

Starting with the biggest issue, that would go under ‘animation importing’… ever since Unity released the Animation Rigging package, I’ve been pouring over every resource I could trying to figure out how to avoid its destructive workflows.
Specifically - Animation rigging demands that I include rigs on the hierarchy, and then recommends that I edit my animation to animate when those rigs should apply or not (which makes sense, animations let you fine tune things)… except… In order to make high quality animations, the ideal is to use a power tool - DCC applications such as Blender or Maya or what have you. When bringing over FBX animations, they cannot be edited in Unity. There was this one video from the Animation Rigging talks at Unite I believe, that recommended you duplicate your animation in the unity project view, and then edit the duplicate. This destroys the link between the animation’s original keys - authored in the DCC , in order to animate some new ones that are unity specific. Basically - once you do this there is no going back, you have to start using unity to author any changes your animation will need. It is far from ideal, and forces animators comfortable in their applications to try and use unity - with its lack of power tools, instead. I’ve yet to find any possible, reasonable alternative, that gives me full preview of what I’m doing when working with the rigs. I’d love to animate the rigs entirely separately from my original animations, but still get a preview of how they’ll affect the animation.

Switching to another issue - right now animation events feel sorely lacking. In Unreal Engine, an alternative system by name of Animation Notifications (or Notifies) offers a far richer experience. This mainly manifests when trying to author particles, audio, or similar aspects for your animation to play. AnimNotifies let you set a beginning & end event in an animation, showing as a singular track piece, similar to how Unity’s recent Timeline does. On those tracks, you can assign rich information such as choosing what particle system should be played, what audio clip should play, and if your added effects should be attached to any relevant sockets (such as a sword trail being attached to sword start and end sockets, or stomp audio at the feet). Unity has no clean alternative to this - sure, I could force these objects permanently into my hierarchy, duplicate my fbx animation, and try to set keyframes to enable and disable the relevant audio / particle system components, but this is hard wiring and unclean - both to the reason mentioned before on destructive workflow, and on the lack of flexibility to replace what those anim notifies would do at runtime. (Such as, replacing the particle system to spawn based on character’s unlocked abilities)

Another somewhat complex topic - there is no way to enforce the Animator to sample every key on the way to its goal. I’d like there to be a way to enforce that - even if just for specific animation events. Right now you can’t enforce an animation to happen at the exact time you’d like - even with animation events. If I were to have an angular clock hand spinning in a circle, with animation events marked on hours 3 / 6 / 9, and asked unity to shoot an infinitely extending line (or a fireball) towards where the clock hand is pointing, there is no guarantee it will actually shoot those fireballs at 3.0 , 6.0 , or 9.0. These can be rather critical - as with high animation play speeds, such as skipping from 2 to 4 in a single frame, the fireball would shoot towards ‘4’. I understand that as a means of optimization the animator only evaluates the new timed position, but I wish it weren’t a forced case. Attack speed in action games is my main reason to bring this up, with examples including making a clean sword trail that goes through all the path points authored in the animation regardless of frame-rate. FixedUpdate mode for the Animator does not fix this either, as the root is about only evaluating the new position, and not any keyframes in its way.

Scaling down the wishlist complexity… The Animator controllers expose a ‘mirror parameter’ which lets us control whether an animation should be mirrored, but, sadly, this is only exposed in the editor, and not in any of the runtime classes, as far as I can tell. Meaning you can’t dynamically ask whether an animation should mirror or not, without giving named parameters to all of the ones you’d like to flip. This is made more frustrating because you can’t easily reuse the same parameter for two animations if you’d like to only mirror one of them. (A shared parameter would instantly flip the one you’re currently on, versus the one you would transition to)

It would also be nice to be able to set the Animation window to only loop through a subset of the animation (such as the first quarter to last quarter) , and to control the animation window’s play-speed when previewing.

I believe the most important thing for animation work in unity would be to remove the destructive workflows first, as these reduce the time between what the developer wishes to see and what they see. Being able to get an animation that would play what you wish it to play made as fast as possible - with all the gameplay elements involved, would be great.

Thank you for making this thread! I hope to see a day where authoring animations for gameplay in Unity is a better experience!

7 Likes
14

I don’t see any use of runtime mirror parameter since you can do it with two states and can transition to the one you want to (and keep track of) either by using trigger or crossfade().
most probably it would mess up the transition (or should wait one animation frame)

just in case, I checked, it’s probably not possible even in Playables, since Animancer doesn’t have it either
https://kybernetik.com.au/animancer/docs/help/

only evaluating the new position, and not any keyframes in its way

as far as I know, animation is curves, there are no keyframes, when playing an animation.
getting curves of the clip runtime before playing it would help, but still, there are the blend trees (and multiple clips)

1 Like
15

The use is exactly to avoid doubling all your workload. There are a lot of benefits to be gained from mirrored animation in my opinion - even a simple symmetric run cycle & stop animation can have the both animation mirrored to match which leg is more forward when when the running/stopping state changes.

On a related note about playables and mirroring, this is an interesting post .

curves are still represented by their key points, that have timestamps, tangents, and so on, internally, though. Animation events are transitory as well, having a clear timestamp and not much else to go by. They’re not likely to be curves, unless unity actively chooses to represent them as such?

1 Like
16

There are a lot of benefits to be gained from mirrored animation in my opinion - even a simple symmetric run cycle & stop animation can have the both animation mirrored to match which leg is more forward when when the running/stopping state changes.

sure it would be easier, but still doable now.
I’m a bit concerned, whether implementing it wouldn’t cause some limitations in other areas of the animation (and performance overhead because of the calculations). using states for mirrored works well. you can also use blend tree, e.g. 2D with a side parameter, and that’s both sides in one state. (cached always performs better)

there’s for example animator layers (every layer has some performance cost). if you could have the animation clip curves ahead, you wouldn’t need other layers. you just play the curves directly, upperbody, arms or any mask (and even modify them before the animator plays them). Playables had this promise, don’t know how it turned out

17

Hi @UnityChinny . I would like dots animation to achieve that you pay only for the animation feature that is actually being use and battle test and push the animation performance until over limit for mobile platform i.e. Android and iOS. The performance of currently available OOP land animation system is still really bad and u pay a lot of cost even for a lot of features that u are not using it. From what I know even u didn’t use IK feature you still pay the cost for it. I want dots animation to fix and improve this current limitation. So, when u release the new preview version of dots animation I want to you to make sure every line of dots animation code is fully burst compatible.

1 Like
18

Sorry if I missed something here but will the new Animation system be closer to the Legacy animation system or Mecanim?

19

Thanks for the feedback

“…Remember: Make solutions comply with K.I.S.S. Simplicity + Robustness = Win-Win situation for Devs & Artists…”

I particularly love this, and totally agree! Something we are most definitely striving for.

2 Likes
20

While we want to achieve everything in one go, you are right that it is somewhat unrealistic.
However you summed up nicely our guiding principles “…reliable, robust and scalable animation engine…”
Thank you