Floating Origin Physics

Hi,

i’m playing around building a space sim.

To deal with problems of scale, I have implemented floating origins. (Floating Origin (Huge Scenes Support))

Now I wanna add physics, but the problem is that babylon physics write directly to the position of an entity. This is problematic because the position is not the actual position (doublepos is), but the position relative to the camera.

So I think I have the following options:

  • Use Babylon’s built-in physics and try to swap doublepos / position in and out with events (registerBeforePhysicsStep / registerAfterPhysicsStep), if at all possible.

  • Take for example cannon js and use it outside babylon and then each frame sync the doublepos and cannon js body position.

  • Last reserve i wanna avoid: Build basic pseudo-physics around the floating origin implementation.

Can anyone give advice on these options or a better solution?

Thanks for any help.

Edit: @imerso, @RaananW? You worked on the Floating Origin (Huge Scenes Support).

You can solve that with after physics.

Keep a copy of the previous normal position of every object. After physics does its things, you calculate the offset from current object position and previous position. Then you add that to your floating-origin double-position. Bam, solved.

3 Likes

Thanks for the reply.
Like this?:

//this = entity
this.physicsImpostor.registerAfterPhysicsStep( () => {
    
    let offset = this.position.subtract( this.previousPosition );

    this.doublePosition.addInPlace( offset );
} );  

...

//this = origin camera
this.scene.onBeforeActiveMeshesEvaluationObservable.add( () => {
    
    for ( let i = 0; i < this.entityList.length; i++ ) {
        
        let entity = this.entityList[i];

        entity.position.copyFrom( entity.doublePosition ).subtractInPlace( this.doublePosition );
        entity.previousPosition.copyFrom( entity.position );
    }
} );

If so, what positions would I work with?
For example, by applying impulses?

let direction = entity1.doublePosition.subtract( entity2.doublePosition ).normalize(); //same with doublePosition or position
let magnitude = 50;
let contactPoint = entity2.doublePosition; //doublePosition or position?

entity2.physicsImpostor.applyImpulse( direction.scale( magnitude ), contactPoint );

Yes, like that but physics should continue using the normal position. You should not need to change the physics part.

I quickli wrote physics into the floating origin demo from the documents.
Result is the same as in my project, the physics entity doesnt move: Floating-Origin Physics | Playground
Somethings wrong…

PS: The entity class now extends AbstractMesh because it’s the lowest level that works with physics, I think. (Although the docs say that any Babylon object with position and rotationQuaternion can be a physics imposter). But I don’t like that anyway because physics are mainly designed for meshes (with boundingInfo etc for collisions).

Edit: Floating-Origin | Playground …and why do they spin?

It’s tricky I think because you’re trying to resolve each case individually. What I think might help more effectively is to extend / override PhysicsImpostor and/or the BJS physics plug-in to automatically translate between normal and double origin transparently to anything consuming it.

Since the physics sim is separate from the regular scene, and since you’re IIRC ammo.JS, you might be able to get away with populating the physics sim directly from your double flop (heh that sounds fun…) origin

HTH

1 Like

Thanks for the input. I was also thinking of that before writing the post. It seems to make sense to take an existing physics plugin and replace position with doublepos so it simulates with doublepos.

Crazy idea: how about going a step further and going into the internals of Babylon. Give each object a property “positionRelativeToCamera”, calculating posRelToCam = pos - camPos before rendering etc and replacing position with posRelToCam in the internal rendering section. So Babylon uses that internally and externally physics and everything continues to use position as usual. Basically floating origin baked into the engine.

Edit: Or don’t change Babylon, let all use position, just store the position of each entity before rendering, change position to position - cam position, render, set position back to stored. Basically between frames the position is normal, for rendering relative to cam.

I think you’re describing the various world transformation matrices already present… say maybe that’s the ticket!

Create an x form matrix converting double to world space and such, then hook into the appropriate observable for before and/or after the cameras world matrix is computed

Also was thinking that a material plug-in might be appropriate for shaders but I think @sebavan can better speak to that area?

1 Like

You could swap the matrix computation as you want with a material plugin :slight_smile: as long as you can not loose precision while computing it.

Will have a look probably next weekend, overwhelmed now

I made a playground with an alternative way to do floating origin, but again physics dont behave properly. Floating Origin Physics

At the top you can toggle the flags, to see the diffrences.
Visual result should be the same when:

farAwayEnabled = false;
floatingOriginEnabled = false;
physicsEnabled = true;

(disabled)

and

farAwayEnabled = true;
floatingOriginEnabled = true;
physicsEnabled = true;

(enabled)

1 Like

Maybe @Cedric would have a trick for the physics part.

1 Like

There is no guarantee the physics engine uses double for all its computation.
I’m sure Ammo for example uses float32 for collision detection and responde (speed Vs accuracy).
So, the result I see goes in that direction: float accuracy and not enough and you start seeing some jittering.
To fix that, you have to create and simulate the physics world in the view space (centered around 0).
if the object gets too far from the camera, then disable its physics.

1 Like

AIUI, that’s exactly how Kerbal Space Program does it. When in flight mode, a physics “bubble” extends around the currently active vehicle for some distance. Object outside of it go “on rails”, continuing previous courses but largely unaffected by frame by frame physics

1 Like

Yessss finally: Floating Origin Physics !!
Big thanks to all!

3 Likes