BEPUphysics

Hi there

I am currently programming a space simulation (more a game then a simulation, non-commercial) and i am searching for a good PhysicEngine i could use...
Currently BEPU and JibLibX are the one which i think meet my request best. (I looked at Bullet, but it seems as they got problems with big mass ratios; for example a ship colliding with a planet...)

My question now is, does BEPU support such mass ratios?
And is it possible to calculate the gravity dynamic?

thanks in advice

Cobra

does BEPU support such mass ratios?

Yes. A ship colliding with a planet will not have a problem with mass ratios. If that planet were crushing the ship up against another planet, then there'd be an issue with mass ratios.

In other words:
Light on top of Heavy = easy for the solver
Heavy on top of Light = hard for the solver

Bullet has a conceptually similar solver and can handle it too.

You may, however, see size-related problems. Anything close to the size of a real planet colliding with a run-of-the-mill spaceship will be very hard to represent using single precision floating point numbers.

If your planets aren't really that big (say, 100x as large as your ship instead 100,000x), and all you want is to explode when you touch a planet or something, that will work fine. At 100x the size, you might not have perfectly stable resting contacts, but if you're just ramming the planet as a ballistic projectile you really don't need exceptionally fine-grained collision detection.

Some type pairs, like sphere-sphere, sphere-box, and box-box, use special cases which are a lot less sensitive to precision problems and will work just fine for anything that can be reasonably represented with 32-bit floats.

And is it possible to calculate the gravity dynamic?

Gravity is just a force; you can apply forces in whatever way you'd like. The applyImpulse and associated methods apply an 'instant' force on a given frame. If you wanted a force of X 'force units,' you would apply an impulse of X * dt each frame, where dt is the simulation time of each frame (Space.SimulationSettings.TimeStep.TimeStepDuration, 1/60f by default).

Lets say i got a Ship with about 30tonnes mass and 30meters spawn...
Would it be possible to determine the collision when landing on a planet?

And if two ships are flying very fast (lets say about 100'000 km/s) but they are flying in formation, so the relative speed between of those two ships is very small. Is it still possible to make precise collision detection?

if i would take 100m for 1 unit, then the precision would be about 1mm. I think thats precise enough? And the sunsystem is about 7billion km wide, (with the kuipar belt). Then that would be 70billion units.
That is still possible with floats?

Thanks for your information

Cobra

Lets say i got a Ship with about 30tonnes mass and 30meters spawn...
Would it be possible to determine the collision when landing on a planet?

Depends on the planet. 30 meters is perfectly fine for a ship, but if the planet is the size of a real planet, you're going to have problems. If you represent planets as some sort of terrain as you approach with individual triangles which are on the same order of magnitude as the ship itself, the collisions would work okay provided that you have a scheme like described in the link at the bottom of this post that keeps all numbers within reason.

And if two ships are flying very fast (lets say about 100'000 km/s) but they are flying in formation, so the relative speed between of those two ships is very small. Is it still possible to make precise collision detection?

Yes and no. Those are some extreme speeds (1/3 the speed of light). At that speed, you're going to be escaping into floating point hell very quickly.

In v0.14.3 and before, CCD between 'in formation' entities will fail fantastically. v0.15.0 will make those speeds more possible, but that's still way too high for good floating point behavior in general.

If you have a situation where you're flying at 1/3 the speed of light, I'd recommend just doing the simulation local to the formation rather than some absolute point in space. It's not like you'd be interacting meaningfully with things you're passing at that speed anyway (except for maybe causing a massive crater on a planet that was in your way)

Then that would be 70billion units.
That is still possible with floats?

Nope; far from it Technically, floats can represent values of that magnitude (up to ~10^38), but there are very few actual unique values up there available for fine-grained simulation. Rendering wouldn't even look right, let alone physics.

You will have to manage the simulation in some other way so that the numbers are always reasonable. See here for an approach to dealing with super-massive simulation sizes:
http://www.bepu-games.com/forums/viewto ... ?f=4&t=971

Basically, the active simulation is always 'local' to the origin. Numbers never get too big.

I got an idea about that...

I could make the center of the physics engine at the players-ship center. Then i manage which objects are close to the ship and have to be added to the physics engine.
Or in other words: I only add objects if they got in a radius of 10000km (only a example). Then i just have to know, where are the static objects at the moment (for example planets, suns, etc) and add them dynamicly to the engine.

But of corse I have to draw always the big objects (for exapmle planets)

How about that?

I could make the center of the physics engine at the players-ship center.

That's a possibility, though it would per-frame updates of the state of anything nearby. If you 'move' and still want to be at the origin, then everything else has to move. But the idea of localizing everything is good.

But of corse I have to draw always the big objects (for exapmle planets)

Rendering is more friendly to floating point problems. If everything is local to the player (either approximately through grid cells or otherwise), then the numbers involved won't be ultra-massive for anything that you can actually see in any detail. For really large and far things, you'll need to work something out. However, I'm a physics guy, not a rendering guy