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.
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.
//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 );
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).
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
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?
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.
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
as long as you can not loose precision while computing it.