Bug Some static Colliders from Subscene break if Archetype changed (DisableRendering + more)

This might be a bug / unintended behaviour of Subscenes with Unity Physics. It has been a lengthy derailment of the Subscene workflow thread, but here's my problem:

Some colliders don't work in my subscenes. (shocker, I know! )

TLDR: sample project (60kb) and screenshot in 2nd post.

If I have the subscene open for editing, it's fine (as it all runs as gameobject conversions).

But if I close or reimport the subscene (using its own conversion workflow) and then auto-load it on startup or manually load it while still in edit mode, many colliders won't collide.

I have a GameObjectConversionSystem that runs in GameObjectAfterConversionGroup.

It adds a few IComponentData and ISharedComponentData to all the objects depending on authoring and hierarchy position. (that could be as little as a tag, but normally it holds a few FixedStrings; I did reduce it to a tag and the problem persists)

On some of these, another authoring component exists (usually for a IComponentData that holds a bool and a few FixedStrings for the UI system, but I reduced it to being just a Tag with the same effect).

All affected entities have this IComponentData, all unaffected ones don't. (it also occurs with NonUniformScale on some of the larger elements in the subscene, that was a dead end, that actually is just another fancy way to say "this Entity is of a different archetype" - I don't understand too well what causes NonUniformScale to be added to scaled static bodies, however, this case is what I'd most certainly consider a bug)

Four interesting observations:

• none of these "changed archetype" entities collide (dynamic colliders just move through them)
  changed as in "the archetype they had while the PhysicsShape on them was being converted differs from final archetype"
• all those that kept their archetype collide as expected
• as soon as I change the archetype of even one of these entities, all of them work.
  this is likely because the CollisionWorld.StaticBodies get rebuilt
• scaled colliders with meshrenderers provide an easy repro for this, too.
  if I split the scaled larger colliders into renderer and collider, only the one with the renderer gets the NonUniformScale component, and because the collider entity's archetype stayed the same, it works. Rendering always works, regardless.

My Workaround is to just do that, change one static body entity's archetype and subsequently have the CollisionWorld.StaticBodies be rebuilt. Another workaround is to make all of them dynamic bodies, which of course is not goal-oriented - but for instance adding a PhysicsBodyAuthoring and making THAT static will yield the same malfunction, because the archetype still changes during conversion.

What I suspect happens is... the Subscene seems to load the physics data just raw (which is nice... if it were the correct data). The affected entities now are in different chunks, and are either replaced by other bodies or empty slots. The Physics system fails (or ignores changes) silently, meaning aside from the occasional wrong collider that's really difficult to reproduce but I think I witnessed, for the most part all objects that were moved to a new chunk don't collide.

I also add a ISharedComponentData during conversion at the same time, oddly it appears to not affect this problem as clearly.

Questions:

• am I doing something wrong, can I change the time at which the physics data is finalized in a subscene, or find a slot where my custom conversion system needs to work? It needs all the entities to exists with all their components, so GameObjectAfterConversionGroup
  was the intuitive choice.
• am I right in my assessment that the physics system just auto-loads the chunks and collision world data raw from the subscene as that in turn is auto-loaded, and that doesn't sufficiently trigger the PhysicsWorld queries to change, because a) number of static objects stayed the same and b) none of the components it looks for changed; albeit the chunk layout changed?

 

It took me a long time to reproduce in a minimal scenario, because apparently it requires a Trigger Events collider to also exist. (it can be by the side, totally unrelated to the rest, just needs to be a part of subscene conversion)

I created a demo project in Unity 2020.2.1f1 that illustrates all the problems and also 4 magical ways to fix the bug (that are magical because they totally shouldn't be fixes), either at edit time or at runtime.



I suspect this is memory corruption in the physics system, because of the trigger thing perhaps. It also can go away depending on how you order the game objects in the subscene, which was infuriating to figure out.

 

And my new candidate for a culprit is the DisableRendering tag.
Other tags don't seem to cause this. But if Rendering is disabled and the scene is saved like this, I need to apply one of the magic fixes to revert it, even if half a second into play mode, I re-enable rendering.

I can't fix it by toggling DisableRendering though, I have to toggle another, (entirely unrelated) ICD (I created a special, irrelevant Tag for this)

The newest version of the project also doesn't require the Triggersphere anymore, nor does it work as a fix.

 

Just a short update: I've narrowed the issue down and am working with ECS folks to find a solution. Will keep you posted with any news. Thank you for the patience and great repro!

 

this problem was solved?