I recently wrote a custom floating origin (and, in a way, camera centric rendering) system that replaces (pre-empts) TRSToLocalToWorldSystem by means of write groups, meaning that if an Entity has the FloatingPosition component, its LocalToWorld will be built by the FloatingToLocalToWorldSystem instead. Works like a charm! (big thank you to the folks in the floating origin thread!) Now, I face a minor (?) issue: if there's an Entity with a PhysicsBodySmoothing component, the system doesn't pick that one up, regardless of whether it has a TagExcludePhysics component or not, or whether the smoothing has been disabled via the component's internal state. Question, if I either write my own physics or somehow use DOTS physics for the movement in the floating origin space: How do I make the "WriteGroup'ness" of a third component like PhysicsBodySmoothing not affect my own TRStoLTW system, especially assuming I would very much like to use smoothing, and write the position/time values in my own system? Can I somehow write a special variant of that system that works like the system that applies the interpolation; and where do I put it / how does its query and FilterWriteGroup options differ? A possible alternative is writing a completely separate physics integrator for "open space" versus "bubble space" (where classic short range physics apply), and for visibility checks I'd be needing build a sensible BVH, for which I don't find enough documentation to build and query my own. Using the existing physics world for this is considerably easier, even though I probably have to create some occluder entities that I move around, or I'd face precision issues.