#Need advice on the choosing the animation solution

1 messages · Page 1 of 1 (latest)

uneven isle
#

Hello everyone. I am pretty new one to the Unity DOTS (and only one of usage of usual Unity), and I am wondering which way I should animate units in my RTS game (tbh not only my, as it is a group one-year project in my university. Btw because of that I cannot use paid assets). I have already read the ultimate blog about animation options in Unity (https://forum.unity.com/threads/dots-animation-options-wiki.1339196/) and Rukhanka blog about optimizing smr (https://blog.rukhanka.com/optimizing-smr), so I suppose that generally I have to options to go for:

  1. Use hybrid approach. On the one side it is pretty simple (if I am not mistaken). Also it is original Unity solution, so I don't have to worry about compatibilities and seeking for help in forums. On the other side there are questions about performance of that option
  2. Use GPU ECS Animation Baker (Headfirst Studios) (https://www.headfirststudios.com/theorangecoder). I am not sure it is much more performant than hybrid approach, but I suppose it must be, as all operations will be done in the entities world. Moreover, if I am not mistaken, I can use here Rukhanka optimizations on smr (and I suppose in hybrid approach I can not do that). On the other side it is a third-party product, so I am not sure about its stability and usability. Moreover I am wondering if it is hard to learn, if someone have some info on that...

Info about my project, to understand what I need to animate: there will be low-poly objects with not so detailed animations. But there will be about 1.5 thousand units, I suppose. And it must not require to much from the computer specs (as people, who are assessing our project have good laptops, but mostly good for work - not especially for games).

So can someone please give an advice on my choice here? May be I am missing something or wrong in something? Any help will be welcomed

normal coyote
#
  1. I can run 80,000 animated entities with that package at 60fps
    I can run about 300-500 in hybrid
#

i would say performance isn't even comparable

#

but you need to be aware of all its limitations

#

i wouldn't use it for main entities, only for large crowds

#

i would suggest rukhanka for anything important, players, enemies, etc

#

and gpu for large crowds that have simple animations and only need to blend between specific stuff

uneven isle
#

Well, if I don't have some kind of main character, but only a lot of not very detailed units (people and vehicles), I suppose I can just use GPU ECS Animation Baker from Headfirst Studios for all of them, right? As I understand limitations of it, which you are talking about, is about some details in animation, right? And these details are needed if for example you make a fps game, or something where you can see characters pretty close. Am I right?

What about the Rukhanka asset - I would be happy to use it, but I can't because of the university project's limitations, where it is said that I can not spend even a cent during the project (everything must be done by ourselves or assets must be free to use) UnityChanDown

crystal hedge
#

Honestly, skinning module of Entities Graphics is missing a very important optimization features. It needs take into account frustum culled entities and do not process them at all. Right now skinnig applied to all skinned meshes in world and for large entities count (actually large bone counts) this becomes a performance problem.

#

GPU ECS Animation baker is not free either

uneven isle
#

So there is no good solution right now? Did I understand your idea right?

Also, you are talking about the same optimization, about which you posted a blog recently, right? If so, can I implement it as you did there? Or it is quite hard task to do for a newbee like me?

crystal hedge
# uneven isle So there is no good solution right now? Did I understand your idea right? Also,...

In blog post I have described low-level optimizations. They did not change algorithms significantly and will have maximum benefits in so called "worst case" scenario, when you have all units visible for the camera. Skinned mesh processing reduction will benefit in "normal" game scenarios, when significant portions of entities is not visible. For example large army attacking your base, but camera focused on "hot points" of the battle. Many units will came from offscreen. And you obviously dont need such units to be skinned, but they are now. Maybe I will make such optimization for exisitng Entities Graphics defotmation system, but I cant give any estimates.

uneven isle
#

Understood, thanks for explanations

Anyway even though GPU ECS Animation Baker is not as effective, as animations in general could be, I suppose (from the given info in that thread) it will be okay for my 1.5k units (and even for 3-5k, if my needs will change in the future)

crystal hedge
#

GPU ECS Animation baker has very limited animation blending capabilities. It can blend only two animations and that is all. And blending is performed by final vertex position interpolation which is far from artifact free. As for performance. Here are some tests. Test scene was same as in my post. 50K of lowpoly (500-800 vertices, 10-15 bones) meshes:

#

Unity GameObjects:

#

Rukhanka with default entities graphics:

#

Rukhanka with optimized entities graphics:

#

Scene view the same for all tests:

uneven isle
#

Sorry for a silly question, but "blend 2 animations" means that every unit can have only 2 different animations (so for example, we add run and shoot animations, but reload can not be played at that unit at all)? Or it means that I can mix only 2 animations at any moment (for example unit is running and shooting at the same time, so animations are mixed. Or unit is running and then it slows down until the stop, so running and idle animations are mixed to create a smooth transition between them)?

crystal hedge
#

Only two at a time.

#

And blended animation is a separate animation. So, if you have 3 animations that need to be blended freely between each other, in result you will have 3 + 3 (anim1<->anim2, anim1<->anim3, anim2<->anim3) total unique animations.

uneven isle
#

And in other solutions (where we can blend more than two animations) it would be something like anim1<->(anim2+anim3)? So that anim2+anim3 will be played simultaneously?
If so then can I do the same with the limitations of animation baker? So I first play anim1<->anim2 and after it ends I play anim2+anim3? For example unit starts to run and then it combines the animations od running and shooting?

crystal hedge
#

I am not very familiar of workflow of animation baker. But if this even possible (doubt that) it need to be configured and controlled manually.

#

So, you need to write animation controller system on top of animation baker

uneven isle
#

Okey, then just animate running and shooting as a separate animation in blender :)

Well, all that sounds not so bad, if I am doing large scaled (similar to) RTS game, where I will not have to manage very difficult animations, I suppose
What about performance. Well it doesn't looks like an ideal variant. But as I see it is the only way for me. Again, I will be extremely happy to use Rukhanka animation asset, but limitations of project does not allow me to do that :( So I suppose animation baker is the only left solution for me, because hybrid approach should be even less performant than that (as I understood)

deep lark
#

theres also https://github.com/Bendzae/unity-dots-animation which isnt on the wiki as far as I can tell, and is what I have forked for my own solution. its not a gpu solution, though its quite bare bones as it is but its also way simpler and less invasive than say latio's framework.

GitHub

Simple animation system for the unity dots stack. Contribute to Bendzae/unity-dots-animation development by creating an account on GitHub.

#

i recommend rukhanka if you ever convince them to allow paid assets though 🙂

uneven isle
#

well I tried its sample, and it doesn't looks like very perfomant. Maybe I am doing something wrong, but it is giving me something about 2-5FPS with 2025 bodies on the sample scene. Of course I don't have RTX 30- or something like that (only 1070ti), but 2k bodies is also not so big amount for DOTS, as I understood

uneven isle
deep lark
#

isnt that gpu baker also a paid asset? anyway yeah i think thats in line with what you would have with any cpu solution, gpu gives a good factor more but more limited

uneven isle
#

OMG, you are right, it is also paid

#

That is a very big problem then

#

I suppose I then have to try to use Vertex position baking
There are two repos:
https://gitlab.com/lclemens/animationcooker
https://github.com/maxartz15/VertexAnimation
From the first view, both of them looks usable. But I suppose I will need to test them anyway

GitHub

Vertex animation baking tool, shaders and animation system for Unity DOTS/ECS. - GitHub - maxartz15/VertexAnimation: Vertex animation baking tool, shaders and animation system for Unity DOTS/ECS.

stable pier
uneven isle
#

oh
That is not very good :(
Well, thanks for help everyone! I will try to do something with that problem

zinc marsh
#

Vertex Baking will cost you way more memory

#

than baking bone transforms

uneven isle
#

Yeah, but baking bones is something unavailable to me, unfortunately, as there is no free repo for that thing. And I suppose I will not be able to write something like that by my own, as I am pretty newbie to graphics theme

#

So will have to try to work with this

deep lark
#

maybe scale back expectations? i remember way back in our senior project, it was some dudes custom actionscript engine(I think) and like we had a handful of animated characters in it or something haha. it was a complete failure as far as an actual game, now with unity its so easy to have hundreds of mecanim characters, and pushing more with dots is cutting edge, unity only really recommend dots for seasoned devs and all the solutions out now are all fairly experimental by regular standards

slender dove
uneven isle
# deep lark maybe scale back expectations? i remember way back in our senior project, it was...

Well maybe. But not totally. The thing is that not only I, but some other people have already given a lot of themselves to that project. So I don´t really have the moral right to say "Well, that was a good try, but we will not do this". As it still seems pretty doable. But some corrections to the idea may be needed, yeah. I suppose we will try to decrease the number of units + take some kind of machine setting, so that we will be able to animate some things through the code positioning and rotating (which must be very fast, if I am not mistaken)

uneven isle