Materializing world is fine for calling ZenKit DLL only once and might add small performance improvements. Unfortunately there are two issues as of now:
If we Materialize the world, we also materialize the whole Vobs. From what I understood, materialized objects/structs have no representation inside ZenKit after materializing and are therefore readonly on ZenKit side (e.g. no saving of changed values possible).
Vobs are only materialized as VirtualObjects, but not as subclasses like the unmaterialized ones. But it's needed to fetch specific properties. (see image below)
Suggestions from my current understanding:
Add a world materialization option to stick with Vobs "unmaterialized" and keep the possibility to store them on a savegame later. (As only VobItems will have position changes, I could also think of materializing everything except VobItems)
When creating materialized VirtualObject class, then subclass the actual types as it's done for unmaterialized ones.
If we materialize, we have no handle back to ZenKit for Vobs. But as we want to save changes, we need this and therefore can't use Materialize(). With unmaterialized Vobs, we can use the existing subclassing already.
It's possible to Materialize() certain world elements only. The solution for us is now:
Materializing world is fine for calling ZenKit DLL only once and might add small performance improvements. Unfortunately there are two issues as of now:
Suggestions from my current understanding: