Continuing my investigations, we decided to try the hybrid approach
A few questions (our main goal is to code a deterministic simulation using ECS and not performance)
1- Is ComponentSystem deterministic without us making it non-deterministic by using random numbers with different seeds?
2- Is GameobjectEntity a supported component which will be kept? Is it better to use it or create our own similar system which does the main simulaiton using pure entities and then in a component system updated in the beginning of presentation system update all of our gameobject views?
3- does determinism break if I use MonoBehaviour as component in my Component system’s query or still the fact that entity IDs are deterministic and always on the same order will save me from randomness of all Guids and other non-deterministic stuff in MonoBehaviors
4- Should I expected lots of breaking API changes for such a hybrid scenario (before entities coming out of preview)?
5- If I want to destroy and instantiate GameObjects with GAmeObjectEntity component, I cannot use the commandbuffer right? Should I have my own list which I add requests to and iterate on in a known point in my simulation or there is something built-in for it?
Answer to 1 should be yes, just am asking to be sure about some possible magic thing in the implementation of foreach or something else at the moment.
Nope. Determinism is a lot more consistent. However, not sure about the determinism of the conversion process to make GameObjects into Entities. That ordering might get swapped. If you are doing runtime conversion you might want to do some testing with this. But once a GameObject has an associated Entity, everything is deterministic from there. If the conversion is not deterministic, you still have the ability to reorder the Entities in their chunks which would resolve the problem.
I’m guessing the next release is going to break a few things given that they are spending a lot of time with it and have recently made the announcement that Project Tiny was going to use GameObjectConversion too (something I’m really excited for actually because it is the more powerful authoring workflow from my testing).
Right. You’ll have to build your own. This will generate lots of GC though. Only pure ECS avoids the GC pressure.
I didn’t see GameObjectEntity in the deprication page and in the component either. Where is your info based on.
I hope some unity developers come to the ticket. I’m getting spoiled I guess
GameObjectEntity isn’t marked as obsolete but it was made to work with Proxies/Wrappers (ComponentDataProxy, SharedComponentDataProxy, etc) and they are already marked with an Obsolete attribute in the source.
@elcionap How can I keep the map between the gameobject and entity in the conversion scenario? also how can I do FPS sample style hybrid coding with that if at all? the second question obviously matters less if first is possible.
I know i can code a shared static dictionary of instanceId → gameObject but anything built-in
You can use ConvertToEntity, from the new conversion workflow, to create pure or hybrid entities using game objects, access mono behaviours in ECS systems etc.
ConvertToEntity basically has two conversion modes: “Convert and Destroy” and “Convert and Inject GameObject”. The later keeps the game object and attach the components to the entity. You can access Transforms, Colliders etc.
You can check about the new conversion workflow here .
Obs.: You need to keep sync between the transform by yourself.
Obs2.: Conversion systems can create a duplicate behaviour sometimes. For example, the hybrid render conversion will convert MeshRenderer and MeshFilter to ECS data. But using Inject conversion mode will keep the original MeshRenderer and MeshFilter, making it render twice. You need to take care of this corner cases.