Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm doing a spaceflight simulator in C++ (using Allegro 5), and I realised that I could just use a physics engine instead of writing my own physics.

So that's what I'm doing.

Since this is going to be a 2D only (for simplicity's sake) simulation, I've looked at 2D physics engines only. And since this will be running on low-end hardware, just not using the z-axis of a 3D engine won't work.

I've narrowed it down to the two big physics engines: Box2D and chipmunk. I'm trying out Box2D now, but the manual says that:

Box2D works with floating point numbers and tolerances have to be used to make Box2D perform well. These tolerances have been tuned to work well with meters-kilogram-second (MKS) units. In particular, Box2D has been tuned to work well with moving objects between 0.1 and 10 meters. So this means objects between soup cans and buses in size should work well. Static objects may be up to 50 meters big without too much trouble.

Obviously I'm going to be using Box2D for objects ranging from 100 m to 1.4e9 m (from a ship to the Sun). However, most of the time I'm going to be flying around in a ship (no collisions), or parked on the surface of a planet. Of course, there will also be accelerations of up to 275 m/s/s (at the surface of the Sun).

Is this order of magnitude going to work with Box2D? Has anyone worked with this kind of stuff in Box2D before? Should I just try another physics engine (suggestions welcome)?

share|improve this question
    
That order of magnitude is going to cause you problems in a lot more places than just the physics. You're likely going to want to work out a way to simulate a smaller sub section of the local area. The local surface of the planet where your ship lands is the only place you need to simulate. When you're that close, the surface is very nearly flat, I don't think you'd have issue simulating it as a flat plane or series of boxes at the local landing site. –  Byte56 Mar 15 '13 at 21:30

1 Answer 1

up vote 2 down vote accepted

Well, if you look at it, 1.4e9 is much greater than 50, so obviously it isn't going to work that well. As to whether you should use another physics engine, I'm apprehensive - I can't think of a physics engine that would work well with objects that large. The computations would lose all accuracy - floating point arithmetic only works with numbers that are relatively similar in magnitude - and you may have the issue of overflow.

My personal opinion is that there won't be a (publicly available) physics engine to handle planetary physics, and that it would be best to either make the ship much bigger (and then scale down), or to never come that close to planetary objects - in which case you could use abstract calculations for the planetary physics, and background geometry for the planets, until you come to park - in which case you could then play a cut-scene, or use a different level/world for the landing sequence; this would culminate in a final world for the actual planet. Of course, that many worlds get confusing - it's up to you to decide which way you should go, but I hope I've helped answer your question.

EDIT:

From what you've said, my advised next course of action would be to salvage what you can from your previous physics engine and start again - I still don't think that there's a physics engine out there which can handle planetary physics (but correct me if I'm wrong). In this case, you'd almost certainly benefit from rewriting it from scratch anyways - you'll end up learning a lot more about physics, and it'll likely perform better.

share|improve this answer
    
This is actually a rewrite of a Quick Basic 2D spaceflight simulator (QB, I know), so it just has to be somewhat accurate. To be precise, it's actually a rewrite of my Allegro 4 rewrite of the QB sim, and my Allegro 4 version actually worked, though it used homemade physics. I'm using homemade collision detection/gravity now, I could just continue making my own physics, which would seem like a simpler option. –  Patrick Powns Mar 15 '13 at 21:09
    
@Patrick I'm slightly confused. You're rewriting it for the upgraded version of Allegro (that is, 5 instead of 4), so as far as I know, all that needs to be changed is the API calls (because there was a major change). If you have a perfectly working physics system from before, all I would do is optimise it and update it - no point in reinventing the wheel. –  Polar Mar 15 '13 at 21:29
    
some parts weren't working, and my entire code needed a refactor, so that's what I did. I didn't want to keep public vectors of double pointers to structs, so I just ended up rewriting it while refactoring from Allegro 4 to 5. –  Patrick Powns Mar 15 '13 at 21:32
    
thanks for the edit, if I had enough rep on this stackexchange that would be a +1 –  Patrick Powns Mar 15 '13 at 21:49
    
No problem - presuming you mean that the edit answered your question, you can always accept it as an answer :). Anyways, it feels good to help people. –  Polar Mar 15 '13 at 21:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.