Physics and 64bits Worlds

[philippedasilva]

Hi,

I have an issue I'm making some research for and wondering if you could be of any help.

I'm working on a game with a System wide scale meaning zillions of kms distances. For that reason, I'm currently using a Double precision positioning (I've created a DoubleVector3 for this sole requirement).
Therefore, my objects are positioned in space using real world scaled positions.

For rendering, I'm doing two things:
A. The meshes and shaders use a World Matrix that is built using the Camera position as the origin. Therefore, when getting back to single precision (float) for rendering, the objects never get precision issues.
B. Because of Z buffer precision issues, I'm also scaling down meshes based on the far plane distance of the Projection Matrix of the camera using a proportional algorithm to respect perspective.

Now, I would like to avoid implementing my own physics & collision engine but I, for now, do not see another way.

I first thought to use a similar trick but the Physics are computed first and applied to the Entity then to be rendered. Otherwise, it wouldn't work.
So any advice would be greatly appreciated

Thanks

Philippe

[Norbo]

If your active set at any time is manageable, say, 2000x2000x2000 units, and the rest of the simulation can stay inactive, you could use a grid.

The basic idea is that your camera position determines the currently active 3d grid 'cell.' Entities within the active cell are simulated normally (and probably in adjacent cells when appropriate). Each cell would probably be implemented as a separate Space instance. You might want to force them to share their IThreadManager instance, though it wouldn't be required. You could keep a pool of Spaces around to re-use in activated cells. It might take more than a frame to initialize a space from scratch (especially if you have to add/initialize a bunch of entities or something), so it might be worth it to spread the initialization over multiple frames prior to actually reaching the boundary at which the cell must be activated fully.

When entities cross the cell boundary between spaces, you have to make some tricky choices. Entities cannot belong to two spaces at once, so at the boundary, it will obey the physics of whatever space it currently is in. If the opposite side of the boundary is something that should be collided with, it will look weird until the entity makes it across the boundary. For a space game, this will almost never be observable unless it's something huge like a planet. Huge objects are probably best considered as kinematic with a collision proxy in each space with an overlapping grid cell.

If some low-priority entity crosses a boundary (like an asteroid) into a grid cell that's currently inactive, you could just leave it in some sort of limbo if you come back to it, respawn it, or delete it entirely, depending on how persistent the world needs to be.

An entity's position is also relative to its current space's origin rather than that of the infinite universe. When it reaches a boundary, the entity's position is changed such that it is in the same location in the 'universe' despite being centered on a different local origin. This prevents any physics-related system from having to use the immense "universe" position.

A system that does something like this (with less fudges and hacks) is on the roadmap wishlist, too. I wouldn't recommend waiting on me to implement it though