Question Runtime conversion

As far I as I understand it, in DOTS 1.0 there will not be any runtime conversion?
My game have procedurally generated levels, new one every time you start a level.
While I think it's possible for me to convert all of it, to not use any runtime conversion (even the parts that uses ProBuilder can be worked around I think). There is one part that is really annoying for me.

I've build a framework for the generation code and stepping though the generation steps, which is indispensable when I'm developing the generation code and settings. This dev system only really works as a dev system with classic GameObjects. So when I'm making a new map and writing new generation code, I want to be able to make it all with GameObjects and then convert it in runtime. Then later when that level generation code works well and I'm happy with the result I can convert the whole thing to ECS. But being able to use normal GameObjects during development of that code make it just so much easier.

Will there be any way to convert GameObjects to ECS during runtime in the future?

 

I am not the OP but I have some real life examples for you

I think as long as there are features missing in DOTS land there will always be reasons to convert game objects to entities at runtime.

A quick example would be VR interactions. It is far easier to grab and interact with game objects then entities but maybe I want to convert them to entities after placing them somewhere.
This could be resolved by saving both a GameObject and an Entity Prefab and having one be destroyed while the other is instantiated (which we actually do right now) but as soon as you change something about the GO and want these changes to effect the entity version it gets a lot more tricky.

Another one may be user generated content (e.g. Level Editors)
As GOs are the "authoring format" it might make sense for the player to work with the "authoring format" and later convert that to entities.

 

Yes, it's editor only for the debugging of the generation steps, works outside of play also. The system is a graph based (xNode) structure where all the nodes define a generation step that can be subdivided and "sub-stepped" through endlessly with a IEnumerator system and yield return anywhere in the generation code (so not the C# debugger). There is a context that is kept in memory in the editor (even mostly serialized) so you can pause anywhere and inspect all the GameObjects in the scene, and you can change stuff manually in the scene or in the generation settings, and then continue with the next step. Very handy when you for exaple do "procedural modeling" with ProBuilder and you need to just look at the mesh data and poke it a bit mid-modeling.

I've already converted the first level to 95% pure ECS. The 5% is the ProBuilder, but I can convert that by just transferring the finished ProBuilder mesh to a pre baked entity. And the 95% ECS is much faster so I hope to convert my hole game to use ECS for the generation, purely for the loading times. But even converting the already verified code was quite tricky. I think having the full power of the scene view (gizmos and handles) fully work with ECS would help a lot. But short of that, ECS is just much more brittle and clunky to use with such "exploratory" coding where the scene view tools are also so integral.

I Hope that make sense? I little hard to explain.

Maybe I will come around and find a way to do the whole toolset in ECS 1.0 and it will be fine. But it will mostly likely add significant development time. And from my perspective it's something I might have to do only because you took away a working thing. I understand the reasoning for the new baking system! But the runtime conversion also has real value for me.

Edit. To answer your question a bit more direct. I can bake everything (mostly props) except for the ProBuilder and spline mesh tool results (is there a fully featured ECS based spline tool for runtime use? I think not). But putting it together in the runtime generation code is the part that is much easier to develop with GameObjects and all the editor and scene tools that comes with that.