I’m working on an industrial application that relies on dynamically created GameObjects at runtime. There are multiple pipelines involved getting the resulting GameObjects, like directly loading GLB models from CDN and other tools for render optimizations (combining meshes, combining materials etc.). In short, the existing system downloads byte arrays and then dynamically creates everything from that at runtime.
I’d really like to take advantage of ECS and the improved performance when working with massive amount of objects.
Since the solution dynamically creates everything at runtime, I cannot use the Baker, prefab approach.
With ECS 1.0, is it possible at runtime to grab the data from GameObjects and create entities?
I don’t care if it’s hacky, I just like to know if it’s possible at all and worth pursuing…
void Update()
{
var entityManager = World.DefaultGameObjectWorld.EntityManager;
var entity = entityManager.CreateEntity();
entityManager.AddComponentData(entity, new LocalToWorld{ value = float4x4.TRS(transform.position, transform.rotation, transform.scale )})
entityManager.AddComponentObject(entity, myManagedObject);
}
thats it, runtime baking. now unity’s bakers have way more to them under the hood but the end result is to transform data from user readable formats to runtime friendly formats. worthwhile? basically you need to implement it all yourself - and the obvious performance hit of doing so during runtime.
I understand there is a performance hit when creating entities and adding data and objects at runtime, but as long the performance hit is during the creation process, this is acceptable (for the end user, it will be a “loading” phase).
In essence, what I want to achieve is to break apart an already instantiated gameobject, not hold a reference to the gameobject, and make it into a data oriented representation, by copying all the various data like transform, materials, meshes etc. from memory, and then destroy the gameobject to free this data from managed data. Is this possible?
It’s probably possible, but you would essentially be importing stuff twice with the approach you outlined (as far as I understood).
You go from GLB file to GameObjects to Entities; it’d be much more efficient if you cut out the GameObjects and directly created entities instead.
Aside, what are you using for GLB import? There is glTFast which seems to support creating entities instead of GameObjects, but not sure how experimental that code path is.
Maybe you can see how they do it.
Its possible to author anything as long as you’ve got an EntityCommandBuffer to insert data into.
Which is always.
The con - you’d have to write conversion manually (per “MonoBehaviour” component).
Alternatively you could produce asset bundles via addressables / use content delivery and have a complete data representation prepared beforehand.
Something like:
→ Upload model to the separate server → Add authoring & logic → Output bundle → Consume
I’m using glTFast, and thank you very much for pointing to the entities support (I had missed that one). I will definitely look into that.
In my pipeline I also use Mesh Combiner Studio 2 after glTFast has completed the job of loading and instantiating the gameobject. This is done to vastly improve the rendering performance by reducing the number of draw calls by merging meshes and materials at runtime. Since the loaded data may contain upwards of 500k objects. It will be interesting to experiment with skipping this part, and go directly from GLB to entities.
On a general note, I think it would be very beneficial if it was possible to go from in-memory gameobject representation to entity. There are so many tools and plugins that has been developed over the years for the gameobject / monobehaviour workflow that is hard to replace.
This solution does not work. Some GameObject components are not getting brought over to the entity, such as rigidbody2D and CircleCollider2D in my specific case.
