Space Fighter game - is bullet appropriate?

[KeldorKatarn]

I am considering porting an old open source space fighter game to C# and in the process wanted to port Bullet in my own style adjusted to the graphics engine I plan to use and its scene graph.

Anyway.. the manual speaks about problems with large sizes, distances and mass ratios..

well this game has distances up to 200,000 meters. the space is not always filled totally of course, but there might be objects at one end of that space and object at the other end, since the missions in that game handle multiple "nav points" at which objects are placed which might be invisble but still present while the player is somewhere else...

the ships and gun shots/missiles range from guns shots at sizes of approx. 0.5 meters to capital ships up to 3,000 meters (most of them under 1,000 meters though)

mass ratios.. well.. the missiles have impact, some small drones have small masses, that goes up to some approx realistic mass of a 1,000 meter long capital ship.

So with these things in mind.. is bullet appropriate for this kind of application, or should a less accurate, hand adjusted 'gamey' physics be used and a realistic physics engine like bullet is just not able to handle such large length and mass ratios?

Any input on this would be greatly appreciated.

Thanks

[KeldorKatarn]

Is the question considered stupid or does really noone have an answer to this? The developers themselves maybe?

[Calim]

Hi !
I also intend to write a space-fighter/strategy game/simulation, and originally I planned to simulate a whole star-system
with a quasi-realistic scale, and I thought I'd implement multiple coordinate systems so I would not lose precision.

Bullet is probably able to handle distances of about 200.000 units, if you use the bt32BitAxis3Sweep (see my earlier
post: http://www.bulletphysics.com/Bullet/php ... f=9&t=1470).
What I decided to do is only use the interference detection system of Bullet and try to write my own broadphase and physics, since the MultiSAP broadphase and CCD wasn't (isn't ?) ready yet.

I tried to implement something like kinetic sweep & prune (doesn't test AABB intersections each frame but pre-calculates when AABB edges will meet and stores the information in an event queue, then at the intersection time I perform a CCD test and schedule the impact event or add the objects' (proxies) to the overlapping pair cache), and since I use doubles for position coordinates inside a coordinate system + integer coordinate system indexes I can now have distances up to a light-year (9e12 units). The kinetic part ensures that I don't miss collisions even if objects move at 1e6 units / second (although there might be some syncing issues between the actual simulation and the Kinetic Sorted List of AABB edges).

I'm not sure how it performs in an actual game situation since I couldn't test that yet (and won't be able to for quite some time), but currently it seems fast enough when letting 1000 boxes move around, accelerated, tightly packed (avg. distance 15 units). It scales down (faster) with velocities & distances of the objects so I figured it would be fine with my enormously thin scene density.

The downside is that the code makes direct use of my game objects, since it needs information about the velocities, and uses my Position class with the coordinate system indexes (for transition between coordinate systems, which is handled by an object 'colliding' with the coordinate-system box/boundary and so doesn't need any extra-checking).

I'm not sure whether I'm really going to use my code or switch to Bullet's own broadphase & dynamics, I postponed that decision to when I can actually test it with the rest of the game, which will take a long time anyway and I didn't want to spend my time thinking about collision detection when I wasn't even sure whether my project would even get to the phase where it's needed. And I wanted to code something.

Bye, Christoph.