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 GameObject__After__ConversionGroup
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?
