Integrating with big_space for large worlds

[andoco]

Is it possible to configure avian3d and big_space to work together? I've tried using the default system scheduling of both crates but they seem to fight over setting GlobalTransform so that entities with RigidBody fly away from the FloatingOrigin entity back to nearer the real origin. I think this is because big_space tries to keep GlobalTransform set within its larger world based on the floating origin, while avian sets it based on Position.

I realise the avian physics wouldn't be accurate within the entire larger world, but I was aiming to enable physics on entities that are closer to the FloatingOrigin.

Is it possible to schedule their respective systems in some way to be compatible? Thanks.

[voneiden]

Is it possible to schedule their respective systems in some way to be compatible?

I don't think scheduling will solve the issue, it needs a bit more work. I'm not an expert in either avian or big_space so keep that in mind tough. The key considerations here are, that in bevy, GlobalTransform is relative to the absolute world origin. In big_space, GlobalTransform is relative to the floating origin, right?

Edit: relative to the cell of the floating origin to be specific

If we look at PhysicsTransformConfig we have three key things that are happening:

1. propagate_before_physics - because normally bevy would update GlobalTransform once per frame and physics runs independent of frame rate, there's an option here to update GlobalTransform before physics are calculated. This step is incompatible with big_space because big_space has it's own way to calculate GlobalTransform and that also happens once per frame, so here we would need to propagate through big_space instead.

2. transform_to_position - this one grabs the GlobalTransform and updates Position and Rotation from it. No problem here.

3. position_to_transform - this one is not compatible with big_space. For example for a root level entity, it simply inserts the Position and Rotation back into Transform. This works fine in vanilla bevy since all three values share the same origin. In big_space, this would need to update the Transform using appropriate big_space methods or by applying a delta to the transform.

I'm fairly confident that Avian can work just fine with a (single) floating origin. It is of course important to keep in mind, that all physics that happen must remain reasonably close to that origin (just like it would with normal avian). Supporting multiple origins would be a lot more complicated.