Will the new DOTS Animation System still use State Machines as the "base" Machine for a controller?

I'm sorry for asking this before the system is even put to preview (which according to the roadmap from Unite seems to be coming soon, as it says it will be in preview for 2019.3), but I wanted to ask asap.

In the video, the presenter says specifically that "[we]'ll see a State Machine built on top of that later", after showing it working on an example project.

Title says it, but I will explain, regardless. Mecanim has several problems as is, but my worst one with it always was the fact that I really disliked the way it handles it's abstractions. Animation Layering on a State Machine makes zero sense to me as it currently is, because a blend of multiple state machines is not all I want to do when building my animation systems (IK for one is something I'd like to be able to do pretty much anywhere).

And, as always, it comes to the way UE4 does it, as I have very little imagination, aparently. And the way they do it is: the base machine for the equivalent of a controller is something more akin to a blendtree (although much, much more powerful). In this abstraction, the equivalent to animation layers is as simple as having two State Machine nodes and blending them through a Blend node and passing that to the output node. Which is actually pretty much how it feels to work with Playables.

That is to say, the only thing I can imagine being a feature the current State Machine system provides that would not directly map to a State Machine node in a UE4-equivalent machine can be achieved with close to zero impact, so there is absolutely no loss of power in using that kind of abstraction instead of the State Machine as base we currently have. I'd lose days if I were to talk about the power gained through adopting this approach.

A system like that is something I briefly talked about recently in another topic. I was building it mostly out of a learning standpoint (as are most of my projects), so it's not like I plan on ever doing something real out of it, but it's definitely more in the direction of what I'd want to see as an actual system in Unity.

So I guess what I want to say is: please give us a better abstraction than State Machines as the one and true solution for animation.

 

I didn't know that Unity has state machine. Mecanim was animation graph engine which later you couple with gamelogic
StateMachineBehaviour
(so make in way state machine. So now you are saying that you are trying to decouple again. Current workflow to drag animator component thru-out app so we can SetVariable/Trigger and then send back info from OnState events from StateMachineBehaviour seem not very efficient. Although you have the technology, UnityEvents and Unity Signals used in Timeline, I could assume lack of common picture between Unity tec teams. I've tried to evaluate idea to use events for state machine and playables for animation.