How to keep up with what systems are supported via DOTS

Hi everyone. I am curious if there is a page somewhere that tracks the implementation status of different features in DOTS. For instance, I am interested in integrating SkinnedMeshRenderer style animation in DOTS, but it seems like, as of now, that is not supported. I am only surmising this from searching on Google and the forums for related information and since I don’t find any relevant information, I am assuming it has yet to be implemented.

It would be great if there was a status page of some sort that showed which systems Unity plans to bring to DOTS and display their status if it is currently implemented, scheduled for a specific release, currently in development, or in a backlog. It would also be nice to have it link to related documentation for the systems in question that are available. Does something like this exist and somehow has eluded me, or do I just need to get up to speed on exactly where DOTS is now and keep up-to-date on all DOTS related news?

1 Like

You can look at what was shown at GDC or this roadmap/slides(Dropbox - File Deleted - Simplify your life), or the changelog in the package manager(git repo isn’t updated anymore). They seem to be focused on physics right now, all we have for animations atm are shader based or hybrid.

EDIT: In the package manager website there is an empty page for animation, I wonder if that’s planned soon? (Animation | Package Manager UI website)

I support having a status page, with all the systems that are being converted, current package version, current status (internal/preview/released) and next Unity version in which it will upgrade status.

It’s essential for our planning.
I mean, I’m about to start a UI system. If it’s a month away to preview, I can wait. If it’s a year away, I need to sketch something right now.

It’s all a big mystery right now.

1 Like

I’m not sure if anyone at Unity fully knows that state of all the work that is being done. I think there are a lot of different teams in different divisions that have their own timelines and some are jumping on DOTS faster than others. And some are jumping on DOTS for backend and exposing a MonoBehaviour frontend. Here’s what I’ve been able to gather:

Preview toys we have as packages:

  • DOTS Core
  • Multi-scene streaming
  • Multi-scene authoring
  • Rigid Mesh Rendering
  • Audio
  • Physics
  • Tiny

Toys available on GitHub

  • Cinemachine (despite what the package.json says, it is using a relatively up-to-date version of ECS)
  • Joachim’s GPU animation (temporary example solution using latest ECS)

Clues and speculation about future DOTS stuff

  • Animation - I think it is going to be a while until we see a more full animation solution. I remember seeing a recent post about how animation was going to be similar to Playables, but wasn’t going to be Playables. I think the original intent was for Playables to work with DOTS but the idea was scrapped as they evolved in different directions. So I think they are in the design phases for a new animation system. And the fact that Joachim made the temporary solution furthers my suspicion. Current animation work is using DOTS for MonoBehaviours approach.
  • Lights - They are coming in the next ECS release!
  • Custom Meshes - 2019.3
  • Terrain - There’s a custom collider for it coming. But there’s no authoring workflow for it.
  • Visual Scripting - 2020.1
  • Addressables/Asset pipeline workflow - 2019.2 - 2019.3
  • UI - No word
  • Networking - I haven’t been following but I know that it is being worked on with DOTS in mind
  • SRP as systems - Sounds like priority is getting HDRP out of preview for 2019.3 and then they will start the transition
  • 2D - No word, but they are also doing the DOTS for MonoBehaviour approach, and Tiny is also a thing
  • Timeline - No word
2 Likes

Additionally 2d physics has been mentioned as a separate package coming later.

animation is on the staging registry(has been for some time) though I have not yet been able to get it to work :slight_smile:
audio also recently popped up there too.
I think Joachim’s GPU animation package is more of a different way to leverage dots(animation), to cover different use cases rather than being temporary.

Oh interesting. I might have to dig through the staging registry this weekend and see if I can’t figure it out.

But I definitely agree that Joachim’s approach covers a use case quite opposite of how Unity has traditionally done animation (and how I’m guessing their new animation will work). The only reason I think it is temporary is because I have a hard time imagining the new animation system not including a variant of the technique. The technique is the only technique I know to render animated meshes at massive scale, and that’s just too DOTS for it to not be an included feature. :smile:

Thanks everyone for the good information! I feel like I have a decent grasp as to what state DOTS is in now. Thanks, @DreamingImLatios , for breaking it all down. Joachim’s GPU Animation project looks very interesting. I will check it out!

And if Joachim or anyone else in Unity is reading this, could we potentially get a status page for all things DOTS?

I think the roadmap page is still a good resource, but looks like DOTS systems migration is missing there.

From GDC the best I could determine is that only the core API will be marked as stable by fall. If, like me, you are building a product you intend to ship in the next few years assume that you will need a hybrid approach for the long-term foreseeable future.

As an example, for animation I have taken the following approach to stay job-ified and avoid touching Unity components in my core ECS game loop.

I have a data-driven description of the animations defined in a scriptable object:

I then at runtime convert it into two outputs. The first is an ECS-usable BlobAsset:

And the second is a PlayableGraph implementation for the Unity side (I do not use Mechanim).

I then have two systems. The first is my AnimationSystem running in FixedUpdate. It knows how to operate on the ECS data and controls times, transitions, etc. I can job-ify this because it never needs to touch Unity objects, it just mutates the state of my Entity’s animation.

My other system is the AnimationPresentationSystem. This one runs in the PresentationSystemGroup and simply feeds the current animation state into the PlayableGraphInstance. This one touches Unity (via the Playables API) and thus must be a regular ComponentSystem.

I’ve taken this approach all over my code-base to segregate regular Unity from pure-ECS code. It’s working very well across systems as diverse as steering, pathfinding, AI, and more.

7 Likes

It is worth noting that the blog today gave a pretty good roadmap for networking in DOTS.

Incredible rundown of how to gather an animation working in an ECS system. Any chance you’d be willing to throw this onto a mixamo character in a standalone project and put it up on GitHub? I think I understand what’s going on, but I’m still trying to grok how you switch animation from Walmart to run or run to fall down for example. And how do frames update?

My goal for next week is getting ECS animation working, so I’ll be digging in to this over the next seven days or so.

1 Like

(Trying not to interrupt the conversation flow) For completeness: here is the related, much-under-development official package: GitHub - Unity-Technologies/Unity.Animation.Samples: Repository of projects that showcase the new DOTS animation package (com.unity.animation). )

1 Like