Jump to content
  • Advertisement
Sign in to follow this  
SiS-Shadowman

Physics with a huge scene

This topic is 2791 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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).

Share this post


Link to post
Share on other sites
Advertisement
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.

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?

Share this post


Link to post
Share on other sites
Quote:
Does anyone have a solution to my problem that allows me to continue using a 3rd party physics engine?

I think it's unlikely to find such a thing without going into the realm of academia. Sorry, didn't go into detail in your post, but if you're interested in putting galactic forces into a game you're better off faking it in some way.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :-)

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Noggs
Use doubles!
Provocative, but nevertheless interesting read.

While I don't wholly agree with the blanket statements made in the article (there are some applications for double, and not everyone using them is automatically an idiot), there is a lot of truth in it nevertheless. Fixed point is the way to go in this case.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[Warning what follows is total guesswork - maybe someone who knows more about this can explain correctly]

CPU manufacturers are building general purpose processors, and for that purpose floating-point is a good fit. It handles really small numbers and really big numbers. If they went with fixed point then they would need to arbitrarily fix how many bits to assign to each part of the number. Some applications would work really well with the arbitrary number they chose, lots of other apps would be forced to write their own floating point layer to handle their range of numbers that fall outside of the fixed point range!

You have to work with the hardware available to your target system. If you can afford to take the performance hit and work with your own fixed point format then that's fine. If you're using XNA then personally I would stick with floating point and XNAmath which allows you to leverage SIMD functionality and the FPU registers and units of the CPU. This will involve centering your simulation close to the origin to get maximum accuracy.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!