Other [0.4.0] DMotion - A High Level Animation Framework for DOTS

Current version: v0.4.1 (github repo here)

After some time working on this, I'm happy I finally get to share it here

DMotion is an open-source animation framework and state machine for DOTS built on top of Kinemation.

I've built this tool with usability and performance in mind. The runtime is 100% bursted, and it's currently ~6 times faster than Unity's Mechanim, for 10,000 animated skeletons on screen at the same time.

v0.3.0 is the earliest version were the API is more or less solid, and possibly ready for you to try it out if you are in need of a DOTS animation solution. Bugs are to be expected. If you find any, feel free to open issues or better yet, a Pull Request .

Thanks a lot to everyone that helped test and gave feedbacks on the early versions! And specially to @DreamingImLatios, whose framework allowed me to build this tool

 

Hi
@Dechichi01

Thanks for that great tool

You ask for a reason to use int transitions in github Readme.
I have use them a lot and mostly only int transitions overall.

Why?

Because logically mob can be only in one state simultaneously and in logic it is actually enum of possible states.
Replicating all states as series of bool is error prone (because with 3 booleans you have 8 possible states while enum with 3 states is only 3 possible states) and uncomfortable that's why I use Int transitions

They bad actually because Int is not Enum. So my point is: we need enum transitions so we can just put enum value from logic to animator and see exactly enum transitions in editor.

 

That makes total send and it's a very good idea. I'll add support for enum transitions

 

I actually have no idea how you would add enum support without type punning (generic blobs aren't supported and type IDs for enums aren't stable). And if you go the route of type punning, you might as well just expose the int.

If you do figure something out, let me know, because it is the same use case for animation event parameters.

 

My initial thought is that enums would be an editor only thing. So runtime wise it would be int parameters, but the custom editor would work something like the following: User creates new "enum condition" -> Editor shows a search box to select the enum type -> This type is then used for editing the int value.

The enum type would be stored in the ScriptableObject, but not ever converted to DOTS.

 

i guess you can still skip exposing int and using float as a replacement and as you said enum in the editor but the runtime be using float values?

 

It could be done that way, but there are a lot of performance benefits of making an int specific implementation. For instance the implementation could use ushort (16 bit) or even sbyte (8 bit), which is a big save from floats (32 bits). Float operations on the CPU are also much slower, even if the actual value has no decimals, and there are usually many more aritmethic modules specialized for int operations, versus float operations.

This differences are usually unnoticeable on modern hardware for low mesh counts, but when processing millions of bones, those add up significantly.

 

JEEZ! i'm impress by the gain in performance, last time i tried the stress test, 1000 puppets run at 10-15 fps and run at around 90!, does the ~30% less performant than mecanim you mention in your documentation still stand?

 

That's a good point, this value is incorrect and the performance difference is probably much higher (possibly by one order of magnitude even). I'll re-run the comparison later and update the README.

One important thing: If you want to get an accurate (ish) DOTS performance in Editor, you need to switch a couple of settings. 90 FPS is actually slow for 1000 puppets, and it's probably because of the default Burst settings in editor (which are not the most performant options).

In case you're interested, here's what you need to change to get maximum Burst performance in editor (those settings are not recommended for development, they are only useful if you want to stress test thing)

Spoiler: Burst settings for Editor Stress Tests

• Enable Burst (Jobs -> Burst -> Enable Compilation)
• Enable Synchronous Compilation (Jobs -> Burst -> Synchronous Compilation)
• Disable satefy Checks (Jobs -> Burst -> Safety Checks -> Off)
• Disable Leak Detection (Jobs -> Leak Detection -> Off)
• Disable Jobs Debugger (Jobs -> Jobs Debugger)
• And very important switch the editor to Release Mode (it's on the right side of the bottom bar)

 

Ok, just ran a performance comparison and currently DMotion is ~6 times faster than Unity Mechanim

 

Just tried out the new version, the vent system works perfectly now, but i seem to encounter a new issue:
for what i understand the "has end time" toggle allow you to define where the transition can occure (0means dont even play the clip go to next and 1 = play the clip completly then go next). i tested several case that seems to confirm that until..

In The Clip below we can see after the shot, the character start to reload but shoot before finishing the animation.

PS: the moment he stop shooting and goes back to idle is done manually by the user

here is the StateMachine (with focus on the Reload transition)

Spoiler: StateMachine

EDIT: i tried to replace the reload with the slash and slash forward provided by the samples, and it seems to works with them, my guess is the duration of the reload (~9s) may be the issue

 

by the way, from what i got from the video, the mecanim animator is also GPU bound as all that numbers of batches kills performance


just a question though did you run the mecanim stress test with GPU skinning On Or Off?

 

Thanks for the bug report. You're totally right - end time is broken for clips longer than 1 sec.

I will fix this in a minor release sometime this weekend. In the mean time, if you want to add a quick fix on your local project, here's what you need to do:

• Make sure you're using a local copy of the package (adding via git url in the package managers adds the package as readonly)
  
• Go to

  AnimationStateMachineSmartBlobberSystem.cs, line 139

  , replace whatever is there by this line:

  TransitionEndTime = outTransitionAsset.HasEndTime ? outTransitionAsset.EndTime : -1f,

• Go to

  AnimationTransitionGroup.cs, line 15

  , remove the

  Range(0,1)

  
  
• On your state machine, set the end time as an actual time of the animation (i.e 8.5s, 7.0s, etc)

This should fix the bug.

The settings for the comparison where all the default ones for Unity and URP. I wanted to compare a straightforward implementation on both systems (i.e the Animator update is done in Monobehaviours, even thought it would be faster in a system).

GPU skinning was turned on (FPS is arround 1-2 with GPU skinning off), and URP Dynamic Batches was turned off (I tried turning it on but it made no difference).

You're correct though that the Mechanim example is heavily GPU bound. I have no idea why there are so many batches tbh.

One perhaps useful piece of info: if you run the comparison test with the camera off, which is more or less a comparison of CPU performance only, the results are that DMotion is around 3x faster, rather than 6x. So I would assume 3x would be as close as Mechanim would get, if the GPU side was optimized (?)

 

i have to say this is amazing, but there are a issue with netcode. I installed package to my nedcode projec and got someerror . "Multiple custom ICustomBootstrap specified, ignoring Unity.NetCode.ClientServerBootstrap". i tried gg it but there was nothing.

 

The sample project when imported creates a LatiosBootstrap.cs which is not compatible with NetCode. Delete that file and in the Create menu there should be a Latios -> Bootstrap ->NetCode Standard - Injection Workflow.

 

thanks for that but i cant find way how to create clientworld or server at runtime, do i miss st?

 

You'll have to modify that created bootstrap to add that functionality from the examples.

 

i dont get it. i followed your suggestion, after create clientworld,and serverworld there is no system. the subscene isnt be converted too.

 

Hi @TomDatar, I believe the tool can work with Netcode by follownig @DreamingImLatios instructions (deleting

LatiosBootstrap.cs

and creating a Netcode bootstrap via

Latios -> Bootstrap ->NetCode Standard - Injection Workflow

).

That said, truth is I haven't tested the package with Netcode yet. I'll create a Netcode sample as part of the v0.3.1 (some time next weekend), and update this thread when it's released.

 

i found new error about build

 

Awesome work!

 

Yeah I'm getting the same error when trying to build.

Edit: It works with 0.3.1, nice job!

 

Version 0.3.1 Released!
​

Hey all! Thanks for the feedbacks and bug reports for version 0.3.0. I finally managed to get through them all and released a minor version, mostly with bug fixes, but also with Netcode examples (@TomDatar).

Be aware though that the State Machine data is not replicated in any way (it knows nothing of Netcode). It's the responsibility of the user to update the state machine parameters both in every client. (i.e using a GhostField "speed" to update the corresponding blend parameter on the state machine).​

 

hi,

how do you build the state machines? would it be possible to build two blend trees and doing transition between them, while filling the clips in runtime? so the state machine would be dynamic, and one blend tree plays current, the other blend tree plays next.

do you have things like CrossFade()? (with offset)

do you have normalized time for states?

 

How is the performance against Mesh Animator?

 

i think that comparison with Mesh Animator holds no meaning here as the asset mentioned is a GPU solution for crowds so it might be more performant for crowds with prebaked animations but this is a DOTS based Animation Solution which on the most part runs on the CPU (Except The Skinning Part, That Runs On The GPU)

 

I asked because I created a hybrid engine with Mesh Animator on front and DOTS for physics and more and I was wondering if there would be a gain if I use your solution instead of Mesh Animator. So for me, the comparison was important because, in the end, we all want more performance!

I'm trying to find the best solution for performance with Unity for a big crowd of people. Thank you for any help

 

This is probably more a Kinemation vs Mesh Animator question, as DMotion is built on Kinemation and is quite light on resources relative to what Kinemation is doing.

Mesh Animator falls under the umbrella of animation instancing which includes techniques such as vertex animation textures, bone animation textures, and bone/vertex animation buffers. All of these techniques make the GPU responsible for animation sampling, blending, IK, and whatever else. The CPU will never know where the character is looking, whether a foot is on the ground, ect because it is all done on the GPU. CPU-based animation like Kinemation lets the CPU figure out the transforms of all the bones. And because of that, the CPU can synchronize hurtboxes to bones, use advanced IK setups with world queries on the fly, do ragdoll simulations, attach weapons and cosmetics to bones, ect. It is a performance vs flexibility tradeoff.

So, animation instancing with a good GPU can push upwards to 10k - 1 million instances. Kinemation is more suited for a peak active entity count between 1k - 10k. Notice I said "active" here because you can go beyond those numbers if you don't animate far away entities off screen.

I hope that helps!

 

Thanks a lot for your answer! I did a R&D project 1 year ago and I was able to do ragdoll by creating in the dot physics the ragdoll object and synchronizing a normal skinned mesh on the front. Everything was working but I had so many problems with physics, weird behavior and because the object for the ragdoll was a normal skinned mesh, it was very heavy on cpu (synchronizing each bone). 1 year later, I come back to check what are the evolution of DOTS and if there is a clever and better way for performance to check if I can continue.

The MeshAnimator was used with an hybrid mehtod where I synched the position, rotation, and animation required with a dots physics object moving around. When the character died, I switched to a normal-skinned mesh with synchronized bone in the dots worlds to put the physics burden on DOTS.

I think I achieved what is the best performance possible at that time (or close too). Now, If I understand correctly, the technic for MeshAnimator would still be faster BUT if I change my technic of ragdoll to be with Dmotion, I'll win a lot in performance for when the character died. Am I correct?

I think I'll build a new test project with dmotion and meshanimator and create benchmark with everything to know. It's for an R&D project anyway so I need everything documented. Thanks a lot for your answer and help.

 

I never understood why can't you do both. I have animation instancing rendering and do few bones on the CPU to get slots and whatever I want. It's super easy as I have an array (buffer) with all I need. Plus, the current animation frame is calculated on the CPU side, so I don't have the downsides you mentioned.

The main downside is of course memory footprint as I need a copy of the buffer on both sides CPU and GPU.

 

Not necessarily "faster". It ultimately depends on if you are CPU or GPU bottlenecked. The GPU scales with the total number of vertices across all instances with all techniques. Depending on the specific GPU model, animation instancing might be a little bit harder on the GPU. In the case of CPU animation, the CPU scales with the total number of bones across all instances. Otherwise it scales with the number of instances. At very high instance counts, the number of bones can overwhelm the CPU and make it the bottleneck if the vertex count is kept in check will well-designed LODs. For simple 6 bone characters, that 10k limit becomes more like 50k.

I don't know if you need DMotion for that since it sounds like you just want to copy ragdoll transforms to the bones. That's done at the Kinemation layer. But using Kinemation will definitely be a lot faster that GameObjects for that. If you need help, let me know, but we should probably move that discussion out of this thread.

If you can get it to work, that's an option. It tends to be a very game-specific solution. I've seen slot simulation on the CPU get desynced from the animation on the GPU due to texture compression or differences in floating point calculations between the CPU and the GPU, resulting in jitter or wobble. Also, IK is really tough to do hybrid. Either you do it on the GPU, or you do it on the CPU. And if you do it on the CPU, you get very close to the point where you might as well do the whole character animation on the CPU. And if you do it on the GPU, you run into the CPU positional unawareness issues I mentioned.

 

Can it support mobile platforms?

 

I'm not currently testing the tool in mobile platforms. If you are willing to test it yourself, I'd be happy to help you if you find any error/blockers. Just shoot me a message.

 

Version 0.3.2 Released!
​

Hey all!

Apologies for the silence here. I haven't had extra time to work on the tool recently.

This minor version update is mostly an stability release. I've re-worked the internals of the system to make it more flexible, and added performance benchmark tests to make sure that future features do not create major performance regressions.

After these changes, I've now set the ground work for faster feature development. Moving forward, here's what you should expect for the next versions:

v0.3.3:

• Integer transitions
• Enum transitions (imagine setting an enum for different movement modes, and being able to reference this enum to transition between states)

v0.3.4:

• 2D Blend Trees
• State Machine Overrides (similar to Unity's Animator Override)
• More examples and documentation

v0.3.5:

• Visual debugging for the state machine (similar to Unity's Animator debugger)
• More examples and documentation

v0.3.6: TBD. Possibly real Netcode support. Possibly an end-to-end example. Feature requests?

I don't have an ETA for those yet, since I have a game in the works with lots of pressing demands. But just wanted to assure everyone that this tool will continue to be updated moving forward.

As always, bug reports, feature requests and PRs are always appreciated!

 

the development pace is fine by me as long as it keeps delivering and it is delivering

thank you for your work

 

Hey there,

I appreciate the work you've done on this package. There was a rather large gap in our project when it comes to full dots based animation and this fits it pretty perfectly.

Anyways, I ran into a couple small issues and included my fixes below:

• in StateMachineParameterUtils.cs any set/get functions using FixedString32Bytes don't work
  • AnimationParameterAsset gets the hash using name.GetHashCode() which returns the hash of a string which won't match with the same exact string in a FixedString64Bytes struct. I just changed it to
    
    Code (CSharp):

    1. public int Hash => ((FixedString64Bytes) name).GetHashCode();
  • Since Name in BoolParameter and BlendParameter are FixedString64Bytes I updated the functions to also use FixedString64Bytes.
• ClipSamplingSystem has dependency issues when the JobDebugger is enabled
  • I fixed this by adding sampleNonOptimizedHandle as the dependency of the SampleRootDeltasJob.

Again thank you a ton for putting this out there, it's really great work!

 

Thanks for the fixes, feel free to open a PR if you can. I'll make sure to fix those for the next release!

 

Version 0.3.3 Released!
​

DMotion v0.3.3 is out! According to the plan, this version includes Integer Transitions and Enum Transitions to the workflow (and some bug fixes).

I know several of you have been waiting for this feature for a while. Hope you enjoy it!

 

Hi, I'm very much new to ECS (only started 2 months ago approximately), and I need some help understanding what I'm doing wrong.

I want to play 1 animation clip on repeat, and have added the component in the screenshot.



The error which I get is as follows:

System.ArgumentException: A component with type:{0} has not been added to the entity.
This Exception was thrown from a job compiled with Burst, which has limited exception support.
0x00007ffcd90c1cb2 (d8afb7cf73cca752bc1d31179accbc4) [BufferFromEntity.cs:157] Unity.Entities.BufferFromEntity`1<DMotion.ClipSampler>::Unity.Entities.BufferFromEntity`1<DMotion.ClipSampler>.get_Item
0x00007ffcd90c123b (d8afb7cf73cca752bc1d31179accbc4) [SampleNonOptimizedBones.cs:28] DMotion.SampleNonOptimizedBones:Motion.SampleNonOptimizedBones.Execute
0x00007ffcd90c396b (d8afb7cf73cca752bc1d31179accbc4) [IJobEntityBatch.cs:917] Unity.Entities.JobEntityBatchExtensions.JobEntityBatchProducer`1<DMotion.SampleNonOptimizedBones>.ExecuteInternal
0x00007ffcd90c1011 (d8afb7cf73cca752bc1d31179accbc4) 11A7F2CEA4FE6159
0x00007ff7b4d3f1f0 (Unity) ExecuteJob
0x00007ff7b4d3f4a5 (Unity) ExecuteJobCopyData
0x00007ff7b4d400ff (Unity) ForwardJobForEachToManaged
0x00007ff7b4d3b6cc (Unity) JobQueue::Exec
0x00007ff7b4d3b98a (Unity) JobQueue::ExecuteJobFromHighPriorityStack
0x00007ff7b4d3bf19 (Unity) JobQueue:rocessJobs
0x00007ff7b4d3df7f (Unity) JobQueue::WorkLoop
0x00007ff7b4f36437 (Unity) Thread::RunThreadWrapper
0x00007ffd4bac7034 (KERNEL32) BaseThreadInitThunk
0x00007ffd4c1626a1 (ntdll) RtlUserThreadStart

Is there something I'm missing?

 

It looks like your entity is missing a required DynamicBuffer (ClipSampler in this case). I can't tell more than that without taking a look at the code for PlayAnimationClipAuthoring though.

I actually have created a component exactly for playing a single clip (looped or not), for version v0.3.4. It isn't release yet, but you can access the new code (and a sample) on the feature branch on github.

Try importing the new samples via the Package Manager (image below). Then take a look at the sample 1 - Play Single Clip





Also make sure that:

• You marked your Mesh as Read/Write, on it's import settings (Model tab)
• You have a LatiosBootstrap class (Create -> Latios -> Bootstrap -> Standard Injection workflow)

Hope that helps! If you have other questions feel free to shoot them here. I will also be releasing many new samples + a complete documentation on the next version, so hopefully the onboarding experience will improve.

 

DOTS Motion could be the missing piece of Rival - DOTS character controller. Does anyone have some knowledge on if all three assets would work together making a complete 3rd Person character controller that does basic WASD movement with jump and run on a custom 3D character model?

• Rival DOTS Character Controller
• DMotion
• Latios Framework

 

when i build android or windows with li2cpp, has bug?

 

That's a known issue with IL2CPP where in some configurations with some editor versions, it does not generate "generalized" implementations of generic methods. The "faster (smaller) builds" option fixes it, but only on certain patch versions as on some editor patch versions IL2CPP is just flat-out broken.

I believe it could work, but it is a legal conflict-of-interest for me to experiment. Unity would need to change the license of Rival to something like the Unity Companion License. Note that's specifically a "me" problem and unless @Dechichi01 plans to ship a custom character controller with DMotion, likely doesn't face the same issue.

 

As @DreamingImLatios suggested, try enabling "faster (smaller) builds" in your build settings. The message you're saying is a limitation of Unity's IL2CPP, so DMotion can't work around this.



Also, make sure you're building using a Build Configuration. DOTS 0.51 and can't build correctly via the building settings. They do use some options from there though, like the "faster (smaller) builds.

That's correct, DMotion and Rival can't be bundled together in a single asset due to Unity's license. I do plan to have a complete character controller sample in DMotion using Rival. This sample would be an optional .unitypackage that expects Rival to be present in the project. I think this would achieve something similar to what you're looking for @docchang.

 

Version 0.3.4 Released!
​

Hey all!

Recently I noticed that the biggest pain for most people when using DMotion was the lack of documentation and samples. Some of the API was also not as easy to use as I wanted them to be for a high level system.

So, in this version I've added 10 new samples to DMotion, all explained in a complete documentation, which you can find here. The API was streamlined as well, so achieving most common use cases won't take you more than a couple of lines of code.



If you been thinking on trying the package out, that's a great time to jump in!

Another small, but long awaited feature that was added is the Visual Debugger, that allows you to visualize State Machine data, and change parameters via the editor. You can learn more about it here.




Finally, I would sincerely love to hear more of your feedback on the package, and whether it's being useful to you. Any feedback is highly appreciated!

Hope you enjoy it!

Gabriel

 

hi there

just a quick note

the link to the asset store is not leading to the asset store page, it's leading to the github page

 

Thanks for the note! DMotion is not live in the store yet, so I've updated the message and added a "Coming soon".

 

I'm trying to set a Float parameter in the StateMachine. However, it doesn't seem to resolve FloatParameter object. The BoolParameter is fine and working. Am I missing a reference?

Code (CSharp):

1.  
2. Entities.ForEach((Entity entity, ref DynamicBuffer<BoolParameter> boolParameters, ref DynamicBuffer<FloatParameter> floatParameters, in Parent parent) =>
3. {
4.  
5. });
6.  

 

Sorry, this was a overlook on the latest version, previously FloatParameter was called BlendParameter. I thought I had renamed it for v0.3.4 but looks I didn't. This is fixed now on the latest main branch. Thanks for pointing it out.

 

Thanks I'll just use BlendParameters for now. I keep getting this shader error, have you seen it?