Feedback DOTS Animation is not suitable for large count of animated entities 10k+?

In other thread, I discussed issues with 2500 entities, using unity.animation.
https://forum.unity.com/threads/controlling-animation-related-systems-execution.1086647/

Hitting bottle necks really quick, with increasing count of entities.

I tried now to animates simple 10k boxes, no bones.
It runs quickly to 10ms on my older 8cores CPU.

I really want to give a love to DOTS animation, but at current state, is just making me hitting a wall.







Any thoughts?

In contrast, using GPU HDRP sample.
https://github.com/Unity-Technologies/Unity.Animation.Samples/tree/master/UnityAnimationHDRPExamples
I was able to run 10k+ skeletons with 100 FPS.

10 FPS example, for 100k animated skeletons, no optimization.

 

Animation issues:

• Massive main thread sync point for feeding inputs
• Lots of tiny kernel invocations in Burst with a lot of routing setup/teardown

Rendering issues:

• Skin matrices are not shared between unique skinned meshes using the same rig
• Skin matrices are uploaded regardless of whether the skinned mesh is culled
• Skin matrices are uploaded via memcpy on the main thread rather than writing to the compute buffer in parallel like how the instanced properties are written
• The skinning compute shader may have cache coherency issues

 

@DreamingImLatios
Yeah, I am about to drop unity animation all together, if I wont find solution to that.
I am a bit upset ...

 

Has anybody ever tried storing bone positions/rotations into textures instead of vertex positions? You would have to do the bone/skinning calculations on the GPU I think and I assume that would lower the total amount of characters. However, it seems that it would allow far more animations per character vs storing vertex positions in the texture. I remember reading a blog post or paper about it but have never seen it done in practice. I was eventually going to try it myself, but right now I lack the knowledge to make it work. (Mostly skinning, compute shaders, etc.) Still, I'm curious as to how well it would work.

 

@Bivens32 I remember seeing discussion while ago about it, on the main DOTS forum.
Ant there was also git repo.
I am no sure, if not even made by Joachim him self?

Edit:
joeante/Unity.GPUAnimation

 

I actually used Joachim's solution in one of my first game jams using DOTS, back in Entities 0.1.0.
https://dreaming381.itch.io/sheep-or-fall
It is not immediately obvious because it was meant to be an easter egg, but the sheep kick their legs occasionally. That solution scaled a lot better than what Unity has now. Unfortunately that repo hasn't been updated to the latest hybrid renderer. Although it probably wouldn't take very long to update it since the latest hybrid renderer removed the need for many of the repo's hacks which are currently broken.

 

Count sheeps before sleep?
I have noticed two, which kicked legs.
So why so rare kicking?
Why couldn't all kick legs?
By the design, not for technical issues as I understand?

 

I just looked it up on GitHub. I think the one Joachim posted just stores the xyz position of each vertex inside the texture. Then at runtime, it just reads the positions from the texture and assigns them to the vertices in the shader. It should be the same technique as the videos you posted with the skeletons. What I'm talking about is that you would instead store only the bone positions/rotations inside of a texture. This would save a ton of memory at the cost of more computations inside the shader for all the local/world transformations etc. It would still have the same limitations as the videos you posted as far blending animations goes, but you could probably easily store like 100 animations inside of a single 2k texture or something like that.

 

Because I was too tired to make a proper looping animation. So I just copied the rest pose keyframe and pasted it like 30 seconds out. So all the sheep are technically playing the animation (and paying the performance cost). Whether you see anything interesting is based on a random playback offset set during instantiation.

Joachim's version stores bones in the textures.

 

Here is @Joachim_Ante solution, form 2 years back.
joeante/Unity.GPUAnimation

Sorry for pinging, but hoping you may have some interesting input on the subject

 

Ah, I see. I was reading it wrong. I wonder how well that performs vs the other GPU technique.

 

It's not that long ago if you look at the other branches: https://github.com/joeante/Unity.GPUAnimation/tree/transform-usage

 

Well yeah good point. But seems there was an upgrade to 2020.1, 11 months ago. And some just minor improvements. Nothing new too fancy.

 

I made a vertex animation texture solution a while back for a project, but I never considered doing it for the bones. That could probably save a ton of storage in the long run, considering you'd 1) no longer need a new texture for every different mesh that uses the same rig and 2) not need to store every single vertex in the texture

 

Thank you @ryanslikesocool. This is really nice input indeed.
I skimmed quickly through your repo, to get some brief idea.

However atm, I am also implementing shader based controlled mesh, with bones integration. So until I am done, I will be waiting for my own results