Please excuse if this has been discussed to death, but I am curious to those following a Hybrid approach using Game Objects for rendering how you did this?
My current approach is to use Baker’s to bake an entity. However, I want entities to be visible during authoring so they have a renderable (GameObject) attached to this. This is excluded after baking by having “Baking Only Entity Authoring”.
During runtime, I load up the given GameObject to represent the entity visually. I do this as I do not want to deal with various shortcomings or missing features on the rendering side at this point (like Animation, for example) or lose access to any assets that I own that work solely with GOs (I’m a lone dev, so this matters). I know there are animation packages for entities like Rukhana which seems pretty good, but this only solves one aspect of the challenge.
So I’m curious as to how other people are handling this at the moment? How are you mixing GameObjects with Entities? Or if not, how do you handle missing features like Animation?
Rendering is ultimately a collection of GPU tasks at the end of the day, and consequently, Entities and GameObject rendering mixes a lot better than other parts of the engine. I’d encourage you to at least try to use Entities Graphics and 3rd party solutions for as much as you can, and only rely on hybrid for the things where there really aren’t alternatives. As for hybrid, it depends a bit on use cases. But what you say you do is something I’ve heard quite a few others do, especially in 2D (although I hear more and more switching to NSprite for that use case).
Also, I’m kinda curious what those assets are that you are worried about only being supported as GameObjects. If the asset requires normal renderers be exclusively GameObjects, there’s a decent chance there’s a simple way to achieve the same effect in ECS.
I’m mostly talking about using assets “as-is”. Animation as one part so any assets that I use that are animated will used as game objects or baked via a 3rd party plugin. I’m sure their fine, but I’m also thinking about not taking on anyone else’s WIP or tech debt. I don’t mind learning a new API or package, but one has to pick and choose how much
As for other assets, in the past I’ve used various rendering packages (for example, water renderers) which were all naturally GO based. But stepping back for a minute I suppose I’d say I am still getting a handle on what exactly is and is not supported (via Entities Graphics) and how much it takes to port an asset that is largely GO based via the baking system. I’m not that well versed in that area yet.
For some context: I’ve largely been using various ECS APIs since 2017 starting with Entitas and a few others. So ECS itself is no stranger. But I am just learning DOTS now.
EDIT: A lot of my looking into Hybrid started with Unity UI not being supported.
You also need to weight that tech debt against the technical cost of making the GameObject world and the ECS world talk to each other. You can quickly erode most of the performance of DOTS if you do the bridging wrong. Also, most of the main 3rd-party ECS animation packages are being used in production by multiple studios each. And the author of each one is very responsive and will help you be successful. (Fun fact: I’m one of them, and my tech primarily targets the Animancer and code-driven animation crowd.)
This will vary heavily on an asset-by-asset basis. But I suspect you’ll have relatively few instances of these compared to normal rendered meshes.
Yes. This is a common hybrid target (unless you are looking for world-space text, in which case there are a couple of 3rd-party solutions). But you can still have a hybrid UI and Entities Graphics rendered meshes.
It really sounds like you need to start asking specific questions to better understand which of your use case have good built-in ECS support, which cases are covered by a stable 3rd-party asset, which are trivial to implement in DOTS, and which you are better off sticking to hybrid. I’d be happy to answer such questions. But if you don’t like doing this investigation for every use case, then honestly, you are probably better off using a MonoBehaviour-based ECS and not DOTS.
I’m also curious! What are your ideas with mixing game object physics with ECS?
I have a some GameObject physics based destruction (3d party plug-in). If I want my Entities to interact with the GameObject physics there needs to be a hybrid GameObject. So hybrid would be the only way this could work. I’m still exploring what would be the best way to do things…
These do not mix well at all. I’d personally suggest avoiding the ECS part of DOTS if you need these physics-based assets. But that’s my opinion. Take it with salt. I know one individual had a prototype of NVidia’s blast plugin working in ECS.
