How to keep built-in colliders from getting converted when used in entities subscene?

Hey there ECS community! ECS newcomer here. :frowning:

TLDR: How can someone convert GameObjects to entities using subscenes but keep built-in colliders to not use Unity Physics conversion? Basically a hybrid workflow.

Long version:
I’m trying to use subscenes to convert GameObjects that are meant for rendering only using ECS. But those gameobjects also have mesh colliders or primitive colliders on them because it’s easier to set them up on the same prefabs.

When the subscene with those gamebjects gets converted to entities it also converts the built-in colliders to Unity Physics colliders.
How can I prevent that from happening and keep my colliders as GameObjects while letting the bakers do their thing when converting the rest of the prefabs to entities?

The first thing that came to mind is to create a tagging authoring component and a baking system for it to remove the created Unity Physics colliders and create new GameObjects with corresponding built-in colliders to undo part of the subscene conversion process.
Obviously it created chaos and it’s also not the most logical process to do the round-trip conversion back.

Any thoughts that could point me in right direction would be highly appreciated. ECS is an awesome but big beast to tackle.

Hi,

If you are not converting any colliders, do you need the physic package at all? Is there any feature of the package you are using? If not, you could just not import the physic package and you would have no ecs colliders (or physic component).

For the authoring of the gameobject mesh collider, i’m not sure, but I would go for the gameobject companion : store the collider mesh reference and/or primitive type enum to managed component in a baker, and spawn a gameobject in a runtime system based on the information given by this managed component, and then removing the managed component after the spawn. You probably need all the setup of the companion gameobject (i guess you plan to use classic gameobject rigidbodies for your dynamic objects), with transform sync and cleanup. They are great tutorials out there on how to make companion gameobject, mainly for animation.

Hey wow! Was not expecting anyone to answer so fast!
Thank you so much!

You’re correct. I don’t need the Unity Physics package but there are other packages that have dependencies to it. So I can’t remove it.

That’s exactly what I’m trying to achieve: to have a companion GameObject that has all the components setup on it and its hierarchy unconverted.

Mostly yes. I’m going to use the companion GameObject as a static collider or trigger that will probably also have a setup of components on it including other child GameObjects. But nothing rendering related.

True true, I’m still shoving through them as we speak. It’s just so confusing because I’m mostly getting search results of older ECS approaches related to companion GameObjects that aren’t compatible anymore. I’m not able to find anything that’s using the current state of the ECS framework.
The most tricky part is that I’m trying to keep the companion GameObject hierarchy and its collider components (and other custom components) from being converted/removed to/by ECS (the components might have references setup to them from that hiearchy) and the thought of recreating it from scratch is super daunting. :frowning:

For performance reasons, it would be best if I could find a way for the companion GameObject to not be instantiated and recreated at runtime and be created/replaced at edit-mode during the baking phase.

Really appreciate the super fast reply @Tigrian !
If you have any previous experience with companion GameObjects in ECS I would super super appreciate it if you have any link to a tutorial that you would recommend related to this.
I promise you I don’t suffer from a “let me google that for you” situation and I’m literally knocking my head on the internet for the past 3 days to gather info about this issue.:slight_smile:
I’m just stumbling on the same results of old deprecated approaches. I guess I have to try a different search engine and hopefully might get some different results.:face_with_spiral_eyes:

Ah! Finally managed to find some up-to-date info!
There is a great talk and a video here:

Hi again

For the tutorial references, Wayn games has just released a video about animation in hybrid workflow : Mastering Entity Animation in Unity ECS : Hybrid Workflow Explained (youtube.com). I have not watched it, but his videos are good tutorials for ecs (The forum post you made had his old video)

Your question got my interest, particularly the idea of editor companion (seems a bit risky but I like that), so yesterday I have tried to see if making a companion gameobject in editor is feasible. I have tried to use the fact you can make a baker that targets monobehaviour colliders, to add custom component to all colliders in subscenes.

Also here is how to strip every physics components with a baking system :

[WorldSystemFilter(WorldSystemFilterFlags.BakingSystem)]
[UpdateAfter(typeof(RigidbodyBakingSystem))]
partial struct RemovePhysicsSystem : ISystem
{
    public void OnUpdate(ref SystemState state)
    {
        var queryCollider = SystemAPI.QueryBuilder()
            .WithAll<PhysicsCollider>()
            .Build();
        state.EntityManager.RemoveComponent<PhysicsCollider>(queryCollider);
      
        var queryIndex = SystemAPI.QueryBuilder()
            .WithAll<PhysicsWorldIndex>()
            .Build();
        state.EntityManager.RemoveComponent<PhysicsWorldIndex>(queryIndex);
        var queryPhysicsVelocity = SystemAPI.QueryBuilder()
            .WithAll<PhysicsVelocity>()
            .Build();
        state.EntityManager.RemoveComponent<PhysicsVelocity>(queryPhysicsVelocity);
        var queryPhysicsMass = SystemAPI.QueryBuilder()
            .WithAll<PhysicsMass>()
            .Build();
        state.EntityManager.RemoveComponent<PhysicsMass>(queryPhysicsMass);
        var queryPhysicsDamping = SystemAPI.QueryBuilder()
            .WithAll<PhysicsDamping>()
            .Build();
        state.EntityManager.RemoveComponent<PhysicsDamping>(queryPhysicsDamping);
    }
}

I then made a system to manage a companion gameobject during editor time. It mostly works, but there is one issue that I think is hard to fix :
When you close and open subscenes, the whole subscen is rebaked, and all the old data is scraped (including the sacrilegeous baking cleanupcomponent). The Instantiation system is triggered again, and the companions are spawned again, making duplicates. Because the cleanup component seems to be manually removed at scene opening, the destruction system does not trigger, and you don’t get the behavior wanted (deletion of old gameobject and instantiation of new one)

But otherwise, everything else works : When you remove the collider from a gameobject in a subscene the companion is destroyed, and when you destroy the gameobject in a subscene, the companion is also destroyed.

(There are also a few details to add, like primitives baking and movement of the companion when you move your authoring gameobjects)

I will try a few things to see if we can not get rid of the duplicate.

9749020–1395115–Systems.cs (5.44 KB)
9749020–1395118–TestBaker.cs (1.25 KB)

Firstly, @Tigrian , I cannot express the amount of gratitude for going this far to help me better understand these new “waters”. You went above and beyond what I would have dared to ask. Thank you so so much!
I’ve been chopping at this approach since yesterday so hence my delayed answer.

Related to the editor companion in-editor GameObject idea, yep, it’s related to a design-time GameObjects companion system I’m trying to build around it for working with ECS in a hybrid way.
I noticed that in a hybrid ECS workflow if you have entities that are placed at design-time in editor and you need one or more companion GameObjects for an entity, it’s not efficient at all to have them be instantiated at runtime as prefabs as most ECS hybrid workflow tutorials show. Sure if you really need it and have runtime created entities that need GO companions then it makes sense there with the usual ECS hybrid workflow shown in various tutorials.

Your code sample put me on the right path! Really appreciated!
Still have some ECS errors caused by the RemovePhysicsSystem because it won’t work on my side when trying to remove PhysicsColliders and the rest of the DOTS phyiscs components when dealing with prefabs that have the colliders on a child gameobject (part of that prefab). Something messes up some internal ECS native containers and hashmaps.
With normal GameObjects in the hierarchy there’s no problem. :face_with_spiral_eyes:

But I’ll get to the bottom of that eventually.
Again, thank you so much for the imense help!

Hi,
Quick answer for the prefab bug, i’m sorry i did not thought of including the prefabs options. I’m not gonna let you wander more on this errors, when i know the solution : add a .WithOptions(EntityQueryOptions.Include Prefab) to each of the physics query. The others query also need this options if you want them to work with prefabs.

As always, super mega appreciate it @Tigrian !!! :wink:
The system got complicated pretty fast.
It’s very unstable so far due to some Unity entities errors. I’ll keep at it some more.

Keep me posted if you manage to find a way to sort this out. I would love to know if such workflows can be done.

Hi @zenbin3d

I have just stumbled (while searching something completely different) on a menu in the project settings that allow to disable a whole baking assembly. Go to Project Settings->Entities->Build and add the Unity.physics.Hybrid to the excluded assembly list. No physic bakers will run after this. So much simpler than removing everything by hand (or using internals to remove them from the bakers to bake) :slight_smile:

I don’t know how I miss this feature before :roll_eyes:.

1 Like

Hey that’s super useful indeed! :wink: I don’t know how I missed it either from all my google searches.
This can act as a super useful safety mechanism in my case and altough it does solve part of the problem, I still need to build the at-edit-mode gameobjects companions system because a GameObject inside an entity prefab can have other MonoBehaviours for collision events handling on some of the colliders that trigger some VFX and/or SFX.

So basically a companion GameObject can have a hierarchy of interconnected MonoBehaviours, events, VFX, SFX that aren’t ECS compatible. Only the visuals are rendered in ECS mode.
An entity prefab would be placed and configured at edit-mode in subscenes and this system would automatically handle their child GameObjects that are “tagged” with a “EditorGameObjectCompanion” component for example to remove them from the ECS subscenes and keep a clone of them in normal scenes (for a hybrid workflow).

But I’ll keep you posted about further development on this for sure. Working on it as we speak.
Really appreciate your support and help @Tigrian ! :sunglasses: