Question Companion GameObject in Entities 1.0 with 2D Spriterenderer is not working

Hi, I have now tried multiple times to implement a 2D Spriterenderer that just follows one of my Entities. I just seem to not be able to get it to work.

• I have an AddTrackingGO Component which has a Prefab which points to Prefab with a Spriterenderer.
• System 1 then removes AddTrackingGO, instantiates the Prefab and adds another Component TrackingGO which includes the instantiated Gameobject.
  
• System 2 copies over the transform information from the entity to the TrackingGO.Value Gameobject.
  
• All of this seems to work - the TrackingGO exists on my player object, I see the Gameobject it is referencing in the Entities hierarchy and the normal hierarchy.
  
• However, I do not see the rendered Sprite. Only when I exit the game, I will see the sprite being rendered into the scene.

Can anyone point me to a working example of this kind of setup (or other workarounds to get ECS+2D working right now)? That would be very helpful.

 

Apparently, one can just add a `SpriteRenderer` to the Gameobject and there is a default baker for it and it works! So thats great. What the Baker does however is:

Code (CSharp):

1.     class SpriteRendererCompanionBaker : Baker<SpriteRenderer>
2.     {
3.         public override void Bake(SpriteRenderer authoring)
4.         {
5.             // Setting companions to Dynamic
6.             var entity = GetEntity(TransformUsageFlags.Dynamic);
7.             AddComponentObject(entity, authoring);
8.         }
9.     }

which confuses me. The `SpriteRenderer authoring` authoring will still be pointint toward the original GO, which however will be destroyed after the baking process? Or does Unity somehow automatically detect that there are still pointers to that GO and it cannot be destroyed? The situation gets more confusing, since if I now check the `Runtime` of the Entity, I see the following component

which has a three times cloned Player GO? Where/why does all this cloning happen?
This cloned GO however seems to automatically keep track of the position of my Entity.

Can anyone bring any light into this dark magic?

 

I don't know exactly how it does it, but all this dark magic is located in the hybrid versions of the entities, scenes and transform packages. com.unity.entities/Unity.Entities.Hybrid/BakingCompanionComponentSystem and com.unity.entities/Unity.Scenes/Hybrid/CompanionSceneUtility are a couple to get you started. All the supported types are located in /Unity.Entities.Hybrid.HybridComponents/CompanionComponentSupportedTypes.
There's also the runtime CompanionGameObjectUpdateSystem and CompanionGameObjectUpdateTransformSystem which is what synchs the GameObject with Entity. Source is there for all of these.

It looks like it moves objects between scenes, at least in the editor, which is likely why you end up with all these cloned objects and why you can't see these GameObjects in the hierarchy window.
It's a pretty good system and I'd use it if you just want the GameObject to follow the entity. It falls apart when using 2D physics though which is why I use the prefab technique.

I don't know why your prefab version wasn't working but I'd check the actual GameObject position is updating in line with the Entity and that it's actually located within the camera view.
Also make sure you're not mixing Unity's Companion system with your own prefab system. If you use AddComponentObject with a Unity component in any bakers, Unity is going to create its own Companion GameObject.

There are examples of prefab and synching in the samples here.

 

When I was trying to stick with hybrid approach I've ended up with tones of companion gameobjects, lots of slow managed system which can't normally use busrt / jobs. Of course if I would have few hybrid entities like rarely spawned VFX graph effects then I wouldn't do anything, but in my game I want to have hundreds of sprites, so I've implemented NSprites and still extend it with custom solutions. It is not that simple as use built-in render but it gives you performance.