How do you deal with the deficiencies of floating point numbers when you have a really large range of numbers? Let's suppose I want to simulate an entire solar system, which is (in our case) roughly about 50au ~= 7.5x10^9km = 7.5x10^12m. Seems pretty impossible, even if I only wanted to achieve a precision of 1m, since 32bit floating point numbers roughly grant a precision of 7 decimals: The simulation would become unstable when it's far away from the origin.

My problem arises from using a 3rd party physics engine which is limited to 32bit precision (it seems that most are).
One solution would be to shift the origin every now and then, but I would have to restrict the most important action around this origin and also never can have action in 2 places (separated by a great distance) at once. I've thought about creating separate scenes (of different origins), but I can't come up with a general solution to moving objects from one scene to the other (what about objects overlapping the scene?).
Does anyone have a solution to my problem that allows me to continue using a 3rd party physics engine?

The second possibility is to create my own number class (probably fixed point) and only implementing the physics I need (which is only collision detection, but it's still a lot of work). I'm sure I can implement that, but I have no clue how this would affect performance (probably in a bad way). Do you have any experience in this sort of thing? It is probably really time consuming, since in the end, I have to reimplement alot of basic mathematical functions as well (most notably square root and trigonometric functions).

Thanks for your answers :)

Quote:Original post by Noggs
Use doubles!

Firstly I don't know of any physics middleware solutions which will model a solar system, or galaxies. Plus you probably don't want planets colliding with each other to act like rigid bodies :)

So I would assume that you are going to be simulating the galactic scale stuff yourself, and that you might want the physics middleware to handle... the ships and asteroids etc? If that's the case you probably only want to simulate that stuff when it's near to the camera so chances are you won't come up against floating point inaccuracies anyway. Anything further away could be approximated.

You're right, I only plan to use the physis middleware for ships and projectiles. Currently I'm working with bulletsharp compiled against xna, uses all of XNAs primitives and thus is bound to single precision.

However your idea could work: I would have to "move" the physics simulation with the player: Every now and then I would then set a new origin for the physics simulation, adjust all coordinates and remove those objects that are too far to be simulated this way. Movement of the latter will then be simulated by a cheaper method than a full physics simulation.

Quote:
By the way if you are only simulating planets and other spherical objects then the collision detection will be super simple and cheap, and should be easy to implement yourself.

Am I close?

Unfortunately I need collision detection with other bodies as well, at least OBBs. There are plenty tutorials around the web, but I don't want to reimplement the wheel if I don't have to.

Hi,

May I suggest a hybrid scheme ? You would definitely need to simulate "islands" (is that the common name ?) or in simple language - every group of entities in your game that are close to one another need to be simulated in the same coordinate system.

In an engine I wrote (but didn't finish) I had the concept of spatial cells. Each cell, conceptually, is a micro-cosmos and has its own coordinate system. Objects
in the game that enter the cell live within its coordinate system.
Its like having several "world transforms" or just several worlds.

The laws governing how and when objects pass from cell to cell can be whatever you want them to be.

So basically, action in two different places in your solar system will be modeled by having two different cells, i.e: two different origins. It works really well and can be used with streaming algorithms to create the illusion of a fluid giant world.

Now, for the representation of the solar bodies themselves. You may recall (or not) that the conic motion paths that are defined by Kepler's laws can be scaled without a problem. So you can have the simulation of the bodies run in a much smaller scale.

You next worries would be to:

1. Determine how and when solar objects may interact with any spatial cell (or origin).

2. How do you scale everything down so that you can properly render everything, assuming its even possible to view everything with one camera (I doubt it).

Just make sure you have a very decent skybox for the background and you'll be fine :-)

Quote:Original post by voguemaster
Hi,

May I suggest a hybrid scheme ? You would definitely need to simulate "islands" (is that the common name ?) or in simple language - every group of entities in your game that are close to one another need to be simulated in the same coordinate system.

In an engine I wrote (but didn't finish) I had the concept of spatial cells. Each cell, conceptually, is a micro-cosmos and has its own coordinate system. Objects
in the game that enter the cell live within its coordinate system.
Its like having several "world transforms" or just several worlds.

The laws governing how and when objects pass from cell to cell can be whatever you want them to be.

So basically, action in two different places in your solar system will be modeled by having two different cells, i.e: two different origins. It works really well and can be used with streaming algorithms to create the illusion of a fluid giant world.

I like the idea, but I see several problems with that approach. Imagine 2 objects in 2 different cells, flying towards each other. If they were to collide right at the border, there's a point when the bounding boxes overlap the border and still don't collide with each other, since they're in 2 separate simulations. It might be solved by adding those objects in both simulations and try to keep them in sync (applying forces etc...).

The second problem is the performance drop if there's action at adjacent planes (2 cells), borders (4 cells) or vertices (8 cells). It would involve a lot of transitions between those scenes.

I'm not sure if those problems can be overcome that easily.

Quote:
Now, for the representation of the solar bodies themselves. You may recall (or not) that the conic motion paths that are defined by Kepler's laws can be scaled without a problem. So you can have the simulation of the bodies run in a much smaller scale.

Yep, that was my idea as well.

Quote:
You next worries would be to:

1. Determine how and when solar objects may interact with any spatial cell (or origin).
2. How do you scale everything down so that you can properly render everything, assuming its even possible to view everything with one camera (I doubt it).

Just make sure you have a very decent skybox for the background and you'll be fine :-)

1. That's a tough one. I haven't really thought about that one yet.
2. Since space is already partitioned by those cells, I could use that for culling as well.

With so many problems to face, I'm just glad I already got that skybox :)

I've heard that rule before and he may be right.
The point is, implementing fixed point math seems quite easy, but it involves writing physics from scraps if you don't have the source code or a generic solution at hand. On the other hand, some physics middleware already support double precision (bullet for itself, not the XNA port) so I understand how it's easy to simply use double precision instead of reinventing the wheel.

But I'm really curios, why did floating point math become sooo popular? All physics middleware I know of uses floating point math (I've heard some consoles only support fixed point, so my point may only be valid to desktop games).
Floating point math is much harder to grasp than fixed point, and when applied to games, makes testing a real pain in the rear end. Your math might work until you're x units away from the origin. Then all kind of creepy stuff happens.