With the Unity.Entities release today, we are adding support for SubScenes and the new ConvertToEntity script. The main concept is that instead of using ComponentDataProxy / ComponentDataWrapper. We simply convert existing game objects or MonoBehaviours to pure entity data. This is the same workflow we used to build the MegaCity demo.
This makes it possible to create content for Unity.Entities in an effective way.
ConvertToEntity is great for getting started in a simple scene and see the conversion workflow doing itās thing, but it doesnāt help with improving load times. SubScenes do. Essentially when saving the scene, we also write out a cached entity binary representation. SubScenes is what allowed the megacity to scale, since we only ever load the game object representation for editing a specific part of the world:
Just adding a note that new Entities release doesnāt work on 2019.2.0a6 due to missing API there (Edit: Unity just released 2019.2.0a7. New Entities do run with it :)) New samples also run fine on 2019.1.0b4.
For Subscene samples, one has to hit the āRebuild Entity Cacheā on the sample scenes, otherwise new samples were really straight forward (I really dig the clarity on current samples).
Iām curious to try out this approach, especially in more complex scenarios to see how it holds up.
Iāve been thinking for a while about what a PureECS āprefab editorā could look like, and I havenāt yet been able to imagine something good and user-friendly (thatās not to say itās impossible; just that I personally couldnāt come up with anything yet). So I think this conversion workflow has potential
More specifically, Iām thinking about what it would be like to create a very complex prefab with complex logic in it, such as an animated character with:
a bone hierarchy (one entity per bone, and possibly one more entity for the entire ārigā)
hit boxes (one entity per collider)
ragdoll setup (one entity per rigidbody and one more entity per collider, potentially. Maybe even one more entity per joint)
a skinned mesh renderer
a character controller capsule
a āCharacterManagerā component that has references to character Bones, Meshes, Materials and other Prefabs for all sorts of purposes (in the case of Meshes, Materials and Prefabs, they cannot live on a IComponentData so that would be something to think about. And in the case of Bone references, they would be references to the specific Bone entities of that character instance). How could those āreferencesā be edited in GameObject mode and then converted to ECS?
@Joachim_Ante_1 , awesome work. Btw is that still long way to go to have pure entity editing at Scene? Will I able to edit current Game Object and entity together at the same Scene when this feature arrives?
We convert whole transform hierarchies. You can have as many references to other objects as you like using Entity refs on the component data side. So all of this can be done now.
Also do note, that referenced prefabs as shown in the spawner sample support instantiated linkedentitygroup. Meaning you have full prefab workflows, where you can instantiate a whole collection of entities in one group just like Instantiate(GameObject) clones the whole sub-hierarchy and remaps any references. It makes the whole thing all of a sudden feel much more like Unity.
The conversion workflow is useful because it lets us convert existing content, scenes, prefabs and the output from existing tools.
It lets us have useful tooling today.
In parallel we are developing dedicated entity editing tools.
But in fact the principle there is the same. Editor and Runtime representation is different. For editing you want larger components, at runtime you want to split it out into small atomic pieces. The new entity editing tool is just much more in depth built specifically for entities. Does a better job visualizing these transformations.
Hi, Can I use this new subscene system for partly streamed world? in example, load subscenes which is located nearby camera only. Current subscene systems seems that load all subscenes automatically. Can I customize loading strategy?
Also, how about scene-related asset, especially lightmap. I baked lightmap with subscenes, but it disappeared when I play it. (maybe automatically converted RenderMesh does not support lightmap yet?)
Can I customize loading strategy?
Yes. Simply add the RequestSceneLoaded tag component on the scene entity, when you want to load it and conversely remove it when you want to unload. The auto-load checkbox does exactly that.
Lightmap baking is not supported yet by the DOTS renderer.
So Iāve been using scene conversion since p22 or whenever it was added. With p26 Iāve converted this over to new sub scenes (which only took minutes) so it hasnāt been a huge change in my workflow.
Anyway hereās a few notes, using Unity: 2019.1b5, in no particular order.
Keep getting a UI elements / serialization exception if I have the SubScene script selected when playing a scene.
It adds a Translation/Rotation proxy to entities which is an issue if your entity already has the proxy!
Previously I had a few GameObjectEntity prefabs that I had both in scene and I also used at runtime. This means I either had to remove the proxies when I put the object in a scene, or add the proxies when I initialized them at runtime.
Instead I just overrode the TransformConversion with a custom version that did a check before adding the component.
This is based off the previous version of TransformConversion (p24) and I know itās been updated in p26 but Iāve stopped using it so itās just legacy pulled from repo.
Instead of doing this now though, Iāve decided to ditch ComponentDataProxies completely and just rely on IConvertGameObjectToEntity, so this isnāt an issue for me anymore but others might run into it.
Overall, pretty happy with the system, it plugs in nicely to my preferred workflow. Iām pretty sure I had some other feedback when I was converting yesterday but Iāve just woken up and forgotten. Iāll post more as I remember.
It adds a Translation/Rotation proxy to entities which is an issue if your entity already has the proxy!
The idea is that we want everyone to stop using ComponentDataProxy completely. We havenāt deprecated it yet. But i think it fundamentally doesnāt fit the conversion flow conceptā¦
Well thatās good because I decided to stop using them after this update and converted them to IConvertGameObjectToEntity MonoBehaviours instead. Is that the recommended workflow?
Thatās a really good call. The current HybridECS workflow involving GameObjectEntity and ComponentDataProxy has too much coupling between GameObjects and Entities, and frankly too much performance bog in the OnEnable & OnDisable.
Thinking those will be replaced sooner or later, I also converted everything to be using IConvertGameObjectToEntity yesterday and today (effectively getting rid of all GameObjectEntity and managing GO-to-entity relations on my own). Now thereās much better separation between GOs and entities. Using the entity spawner pattern also feels really good and natural. In general, very happy with this release.
And I spend all time to repair (from 0.0.24 to 0.0.26 package)