I’m looking through the Nordeus demo - while trying to extrapolate the patterns into a scratch-pad project of my own. I don’t see any animation controllers in Nordeus (apart from the logo animation control) or TwoStickPure.
Would I put an “animator” within a struct and assign the component as a script?
Looks like “old” style I’m putting a gameobject down with an Animator who has a Controller,Avatar, root motion flag, update mode and culling mode.
Is there a new way to work with these under ECS? does the use of animators (animation controllers, clips etc… ) make this technically a “hybrid”?
I guess I’m trying to understand the new pattern conceptually.
(Also, as a tangent - what is the avatar anyways? Does anyone have a link to something that explains what an avatar is in the context of an animator?)
I’m guessing this will allow you to control animation in the ECS in a more standard way (unlike the Nordeus demo which is all animated on GPU and baked into textures)
I’ll try to experiment with this and see how it goes
EDIT: nevermind, I don’t think this is ECS-ready yet. We still need some sort of SkinnedMeshComponent and AnimationComponent (or do absolutely everything by hand)
Amazing! I’m downloading the new version now to take a look myself.
Edit - hmmm… looks like 2018.2.0b1 seems to break with package com.unity.entities@0.0.11
C:/ProgramData/Unity/cache/packages/staging-packages.unity.com/com.unity.entities@0.0.11/Unity.Entities.Editor/ExtraTypesProvider.cs(6,32): error CS0234: The type or namespace name `Build' does not exist in the namespace `UnityEditor.Experimental'. Are you missing an assembly reference?
I don’t know where to see if the package has updated. Will poke around a bit
You could probably just play a playable without requiring a SkinnedMeshRenderer, but in that case you’d need to handle skinning the mesh yourself. Unity is probably gonna ship their own solution for this pretty soon so I don’t think it’s worth it to try and do this now
The other thing I’m unsure about when it comes to ECS and Playables is that I think Playables need an Animator in order to work. This would make them incompatible with PureECS
I’d really like to know what the devs’ plan is for Rendering & Animation components in PureECS, and how close we are to getting our hands on these systems. Once we have ECS-ready renderers, animators and physics, the ECS will become much more usable for real games
Arguably Animation of this type should run on the GPU as ECS would just end up saturating the CPU/GPU rendering bandwidth with lots of animation updates every frame, e.g:
900 characters with 15 bones = 13,500 Quaternions running in around 216,000 bytes
or 210 Mb @ 60hz (or higher) hits 12.6 Mb/s.
Most CPU/GPU PCI x 16 interfaces can easily handle 100’s to 1000’s of Mb/s so this is well within the boundaries but if you also need to update the meshes and transforms on the CPU the bandwidth will be a lot higher.
Then you will be updating the rest of your game world, particles and meshes so it could become a bottleneck.
Also these types of Vector/Quaternion calculations are often best done by on chip SIMD modules so I can see why you think ECS would be ideal with Burst, however the GPU is just a massive array of dedicated SIMD modules and with the right shader coding this can all run on the GPU with only state changes needing to run on the CPU (something ECS would be great at).
*Assuming the animations are joint only rotations.
@Arowx but you need to use skinned renderers so it’s outside of ECS API and therefore your method of animation is out os the scope of this topic. Best you can do with it is hybrid approach with skinned mesh renderers.
There is still a need for regular animation handling on the CPU with the ECS, so that game logic can properly interface with it and procedural animation becomes possible (custom blending, IK, physics animation/ragdoll, etc…). Handling all animation on the GPU would mean everything has to be pre-baked and you lose a lot of control on it. GPU animation is a great fit for an RTS, but maybe not for a game like Shadow of the Colossus where a lot of the animation is procedural
The skinning definitely can stay on GPU, but there needs to be some kind of ECS system for updating bone poses based on an AnimationClip
Didn’t Unity bring in the ‘Mechanim’(?spelling?) animation system because it was performant and feature rich?
What about mixed animation ECS systems, where you can update the state needed of the animation system via ECS then push the update via the default animation system?
I’m not sure how good Mecanim’s performance actually is (there are many people who think it’s an outdated system, but I haven’t made actual tests to back that up). But that doesn’t even matter, because regardless of how good it is, it cannot be used in Pure ECS.
Pure ECS means no GameObjects. No GameObjects means no Mecanim, and way better performance. Using HybridECS would mean sacrificing a pretty large portion of that performance advantage
I’d also add that Mecanim probably uses the old math types (Vector3, Quaternions) on the C# side instead of the new SIMD-friendly ones, so just with that you’ve got a pretty big loss of potential performance. I don’t think there’s any way around it: there needs to be some kind of very simple AnimatorSystem and AnimatorComponent that can be used to play clips on a PureECS bone hierarchy and PureECS skinnedMesh. The simpler the better. Then, if we want to, we can make a fancy animation node editor on top of it
Is there something planned in the near future for animation in Pure ECS? Something really low-level and equivalent in functionality to animation Playables would be the best
If you read over in the Animation sub forum it sounds like they’re working on some extensive changes to make animations ready to work with the new jobs system but they don’t have a timeline yet.
