The Hybrid assemblies of the Entities 1.2.1 package (specifically, Unity.Entities.Hybrid and Unity.Transforms.Hybrid) contain useful components and systems for associating GameObject instances with entities as well as copying entity transform data to GameObject Transforms during a frame.
Unfortunately, the entity components that make these systems work as well as the Unity components supported for conversion in these systems are closed off as internal so modification to the baking processes as well as querying and processing of entities with these components is not currently possible without replicating the entire system setup manually or embedding the Entities package and modifying it.
I am requesting that the CompanionLink, CompanionLinkTransform, and CompanionReference components in the Unity.Entities.Hybrid assembly be made public so users of the Entities package can write their own queries to process these entities. The immediate use-case I have for this modification is the ability to be able to perform Transform data updates to a companion linked GameObject during Application.onBeforeRender using entity component data. For example, with this new feature, I could use the HYBRID_ENTITIES_CAMERA_CONVERSION script define to enable converting of subscene GameObjects with a Camera component on them then be able to write a query executed during an Application.onBeforeRender callback that processes all entities with CompanionLinkTransform, LocalToWorld, and Camera components, updating the Transform of the Camera using the entity’s LocalToWorld data.
In addition, I also request that the BakingCompanionComponentSystem be modified so the internal collection of Unity components supported for conversion can be externally set to fit the package user’s needs. Right now, the BakingCompanionComponentSystem uses the internal CompanionComponentSupportedTypes class’s static Types field to define the Unity components that should be kept and associated with an entity. This collection should be externally definable so the user can indicate what Unity components their systems can support in a Hybrid fashion.
Without these modifications the Companion GameObject system is not reusable by users and users must re-build these systems almost exactly as they work now to get more flexible functionality.
1 Like
As part of the roadmap they said that every gameobject will have/be an entity.
Either it will be with this system and I don’t think Unity will make these public, especially the list of supported types.
Or it will be a different system and these would be deprecated, in which case, making them public to deprecate them would confuse everyone.
For my part, I implemented my own solution that give you access to any monobehaviour component you would want on an entity. Only downside that need to be worked on would be the mandatory prefab GO for it to work and lack of in scene view representation when authoring. More details here :
1 Like
@WAYNGames Thanks for sending on the details of your solution; it is a great starting point.
I have implemented my own solution as well (a couple of times in different projects now) and used the same setup as the Unity Companion GameObject system so a prefab GameObject is not necessary (integrated companion GameObject scenes; checkout the use of
CompanionGameObjectUtility in BakingCompanionComponentSystem and EditorPlayModeLoader if you haven’t already).
I feel that I should not need to continue to re-implement this solution on my own with the majority of my use cases already covered. I disagree that any of these components should be closed off internally as the consumer of an ECS package (or any package for that matter) should be able to inject their own functionality at any point necessary which at a minimum means making at least the component data public. Code reuse can be a great feature of an ECS coding paradigm, but the component data must remain accessible in order for it to work.
Unless the system is being deprecated right now, whether Unity uses this existing system for a final implementation or deprecates it is irrelevant to my request. If a new system is created, that one should be more “open” as well. Too much Unity created “open source” code feels rigid and I would hope more requests like these could begin to sway that trend in a more open, balanced direction.
A system like this that will control the process of entity creation and association for GameObjects MUST be open or we will be stuck with the decisions Unity makes which might not be right for everyone. This is true now of current GameObject assumptions and they cannot be easily changed.
Plus, Unity doesn’t know how we are trying to use their code or our wants/needs of their systems if we don’t tell them. This is mine. 
3 Likes
