[Design Question] Modeling bases across a solar system

[dumbo2007]

Hi,

I am trying to add physics to a space flight simulation software called Orbiter. It allows bases to be setup in different planets and moons in the solar system. Internally it uses the double data type to deal with the large distances.

I want to add some physics elements to these bases like collision detection, non physical characters etc. Note that these bases are separated by huge distances. There are 3 ways to solve it as far as I know :

1. Since Bullet uses float internally as single point precision is very fast, the objects in each base cant be added by using their distances. They would probably be too far apart for collision detection to work reliably(I am assuming so). So its better to add the bases by allocating each of them a certain volume in a single dynamics world. Say:
   (0,0) - (100,100) for base 1
   (101, 0) - (200, 100) for base 2
   
   Then making sure that objects from 1 volume doesn't go into the others volume.
2. Compiling Bullet with double precision so the large distances are supported and using a single collision world.
3. Using a separate physics world for each base as they are so widely separated anyway and objects will be added to only one world.

I am quite sure option 2 is a bad idea as it will slow down the entire collision detection pipeline.

2 seems like a good idea for extending the bases in the future. I am going to add a lot of objects in a single base : 10 raycast vehicles, 20 non physical characters, 100s of rigid bodies etc. So it may be a good idea to have a separate collision world for each base. But I am not sure if 2 dynamics world is a good idea. Has it been attempted by anyone and how much CPU does it take ?

(1) is the option I am using right now, putting far away objects in separate volumes in a single bullet world.

So I would love to have suggestions on how to proceed.

[darKoram]

So I would love to have suggestions on how to proceed.

Interesting project. I would say 3. is definitely the way to go.
The bullet manual specifically warns against having objects of widely ranging sizes so i would say that rules out 1. and 2. You don't want planet sized objects mixing with vehicle sized objects.

What you want is some kind of level of detail solution:
One scene if you are traveling between planets
Other scenes per planet where the surface is approximated by a plane of sufficient size but no more than say 100x the dimension of the vehicle.

darKoram

[Granyte]

i have a similar situation in my project and bullet reacted surprisingly well with a 65000 radius sphere and many object of varying size (100->0.2) when going under 0.2 glitches started to apear and my renderer was screwing around to so i stoped testing there

i'm testing only with a single planet i have no idea what will happen if i add more then one to a project (using realistic distance would likely simply kill bullet)


how ever in my project i can't use multiple physics world as my projet require some one to be able to shoot a missle from world A and have it land on the face of someone on world B

how ever solar systems will be diferent physic world in my project ;p


in my project i also have the issue of bullet dealing with a realistic world that has no definite mesh since the mesh update as the user get nearer or farther

[dumbo2007]

my projet require some one to be able to shoot a missle from world A and have it land on the face of someone on world B

Well you could do it using multiple worlds also , by removing the rigid body corresponding to the missile from world A after it leaves the bounds of World A. Then initializing a rigid body within the bounds of world B in the appropriate direction and setting its velocity and speed. These can be set up specifically for each rigid body before a sim step.

What you want is some kind of level of detail solution:
One scene if you are traveling between planets
Other scenes per planet where the surface is approximated by a plane of sufficient size but no more than say 100x the dimension of the vehicle.

Yes I have begun working on a level of detail solution where meshes are loaded/unloaded based on camera position and meshes which are visible, have a lower resolution , the farther they are from the camera.

My main concern with using multiple worlds is the CPU usage.If I have just one process with 2 dynamics worlds to update within the time of a single frame, then it may hit the FPS.

Using the multithreaded solvers that Bullet provides may be a solution.

Also since the bases on 2 celestial bodies, say the Earth and the Moon are so far away, I think I can update each world in their own separate thread. So we have 2 threads and perhaps one main thread which runs the Orbiter simulation stuff. Each thread will have their own data so almost no dependence upon each other.

[Granyte]

well that would mean having to convert data from world A to space world


so that the misssile travel in space aka can be intercepted cut shot at etc w/e you wish

and then converted back to world B coordinate space

this also mean that the space world would have to be at least a thousand time les precise then the planet space making rentry in the atmosphere a mather of luck

it also make usage of laser and other weapons that could use a simple raycast instead of a projectile impossible

[Granyte]

no one has a sugestion for a world that cannot be divided?

[dumbo2007]

Well, you could of course use the same physics world, but use 3 different large volumes for the following :

• World A
  Intervening space between A & B
  World B

These volumes are in separate parts of the same physics world. You would need to add/subtract a translation vector, but that by no means affects accuracy.

What I do is ,let Orbiter handle the simulation for the intervening space. Orbiter uses the double data type which is highly accurate for distances spanning the solar system and out to a few AU. The scenes on each planet are handled in a separate Bullet simulation. So the idea that the intervening space will be much less accurate is not true .

You can simulate the missile's flight with Bullet compiled with double precision separately. Or you can simply calculate the position in each time step yourself, again using double for all floating point calculations.

As for the mesh, I also have irregular lunar terrain(based on real Lunar topography data). I have rovers based on the bullet raycast vehicle traversing this terrain, by loading only a small patch of triangles(only 64 in fact in a 8 by 8 points patch) below the vehicle. As it moves the terrain is updated in the direction of movement. The mesh can of course be used to collide with any incoming spacecraft.

[Granyte]

i think that i will try to recompile bullet with double data precision to see if it gives good result i guess the main reason why bullet is not double precision is a performance issue? if so what would be the performance hit 3-4 or 6 time slower?




so loading data on the fly can be done i'm thinking about using the triangle mesh interphase to read a mesh buffer generated with the patch mesh data as i'm currently using a patch lod system in irrlicht this is a video i shot a couple days ago
http://www.youtube.com/watch?v=3zSthN8e ... RQHg6lVNy1

[dumbo2007]

Looks really good, especially the view of space from the planet's surface.

I have tried Bullet with double precision only on some of the demos and they didnt experience any noticeable slow down. But perhaps you can try it with your world. Well Bullet uses a collision margin of 0.04 if I recall correctly. So using float is generally enough as using double means declaring btScalar as double which will mean double is used for everything, thus potentially slowing everything down.

But it maybe a good idea to use double if your world is large and you want everything in 1 dynamics world. Only testing will tell.

[Granyte]

i just updated to bullet to 2.79 and tryed to use CMake to make double precision version

but now i get this in the compiler output

Code: Select all

1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>CelestialBody.obj : error LNK2001: unresolved external symbol "public: virtual float __thiscall btCollisionShape::getContactBreakingThreshold(float)const " (?getContactBreakingThreshold@btCollisionShape@@UBEMM@Z)
1>CelestialBody.obj : error LNK2001: unresolved external symbol "public: virtual float __thiscall btCollisionShape::getAngularMotionDisc(void)const " (?getAngularMotionDisc@btCollisionShape@@UBEMXZ)
1>CelestialBody.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall btCollisionShape::getBoundingSphere(class btVector3 &,float &)const " (?getBoundingSphere@btCollisionShape@@UBEXAAVbtVector3@@AAM@Z)
1>CelestialBody.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall btSphereShape::calculateLocalInertia(float,class btVector3 &)const " (?calculateLocalInertia@btSphereShape@@UBEXMAAVbtVector3@@@Z)
1>CelestialBody.obj : error LNK2001: unresolved external symbol "public: __thiscall btRigidBody::btRigidBody(float,class btMotionState *,class btCollisionShape *,class btVector3 const &)" (??0btRigidBody@@QAE@MPAVbtMotionState@@PAVbtCollisionShape@@ABVbtVector3@@@Z)

as a mather of fact i'm unable to get cmake to output a version working version of bullet 2.79

[dumbo2007]

You need to compile bullet independently, not with your application. CelestialBody.obj(probably from CelestialBody.cpp ?) does not seem to be apart of the Bullet library.

[Granyte]

i have bullet compiled

this happen when i try to compile my application with bullet linked

i just updated the path from the 2.78 folder to the 2.79 folder replaced the exe and bang i get these error

i guess it has to do with Cmake and curently i am unable to set CMake to build a correct solution for bullet 2.79

this is the current output from cmake honestly it's the most painfull tool i ever had to use

Code: Select all

CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 2.8)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP0000".
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at MiniCL/CMakeLists.txt:19 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at MiniCL/CMakeLists.txt:20 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at BulletMultiThreaded/CMakeLists.txt:68 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at BulletMultiThreaded/CMakeLists.txt:69 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at BulletMultiThreaded/GpuSoftBodySolvers/OpenCL/MiniCL/CMakeLists.txt:52 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at BulletMultiThreaded/GpuSoftBodySolvers/OpenCL/MiniCL/CMakeLists.txt:53 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at BulletMultiThreaded/GpuSoftBodySolvers/CPU/CMakeLists.txt:20 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at BulletMultiThreaded/GpuSoftBodySolvers/CPU/CMakeLists.txt:21 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at BulletSoftBody/CMakeLists.txt:41 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at BulletSoftBody/CMakeLists.txt:42 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at BulletCollision/CMakeLists.txt:244 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at BulletCollision/CMakeLists.txt:245 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at BulletDynamics/CMakeLists.txt:80 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at BulletDynamics/CMakeLists.txt:81 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at LinearMath/CMakeLists.txt:43 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.


CMake Error at LinearMath/CMakeLists.txt:44 (SET_TARGET_PROPERTIES):
  set_target_properties called with incorrect number of arguments.

[dumbo2007]

Ok lets forget about double precision for the moment.

Have you tried this : http://bulletphysics.org/mediawiki-1.5. ... om_scratch

[Granyte]

after quite some messing around i manager to get bullet 2.79 to work using cmake but after switching to double precision mode

i get this

Code: Select all

>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>CelestialBody.obj : error LNK2001: unresolved external symbol "public: virtual float __thiscall btCollisionShape::getContactBreakingThreshold(float)const " (?getContactBreakingThreshold@btCollisionShape@@UBEMM@Z)
1>CelestialBody.obj : error LNK2001: unresolved external symbol "public: virtual float __thiscall btCollisionShape::getAngularMotionDisc(void)const " (?getAngularMotionDisc@btCollisionShape@@UBEMXZ)
1>CelestialBody.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall btCollisionShape::getBoundingSphere(class btVector3 &,float &)const " (?getBoundingSphere@btCollisionShape@@UBEXAAVbtVector3@@AAM@Z)
1>CelestialBody.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall btSphereShape::calculateLocalInertia(float,class btVector3 &)const " (?calculateLocalInertia@btSphereShape@@UBEXMAAVbtVector3@@@Z)
1>CelestialBody.obj : error LNK2001: unresolved external symbol "public: __thiscall btRigidBody::btRigidBody(float,class btMotionState *,class btCollisionShape *,class btVector3 const &)" (??0btRigidBody@@QAE@MPAVbtMotionState@@PAVbtCollisionShape@@ABVbtVector3@@@Z)

i assume it comes from this code

Code: Select all

// Set the initial position of the object
	btTransform Transform;
	Transform.setIdentity();
	Transform.setOrigin(TPosition);

	// Give it a default MotionState
	btDefaultMotionState *MotionState = new btDefaultMotionState(Transform);

	// Create the shape
	btCollisionShape *Shape = new btSphereShape(TRadius);

	// Add mass
	btVector3 LocalInertia;
	Shape->calculateLocalInertia(0.0f, LocalInertia);

	// Create the rigid body object
	myRigidBody = new btRigidBody(0.0f, MotionState, Shape, LocalInertia);
	
	// Store a pointer to the irrlicht node so we can update it later
	myRigidBody->setUserPointer((void *)(this));
	myRigidBody->setCollisionFlags( myRigidBody->getCollisionFlags() | btCollisionObject::CF_KINEMATIC_OBJECT);
	myRigidBody->setActivationState(DISABLE_DEACTIVATION);
	

but i don't get how it came from working in 2.78 to not working in 2.79

[Granyte]

taking a break of all these double precision and cmake issues how many polygon can bullet handle in a single btBvhTriangleMeshShape

and keep a decent speed? cause on my current project at 7000 polygon it run fine (200 fps) but when ever i hit 11000 polygon it drop to 1 fps

EDIT after some tweaking i got something to work i can get more then 200 bodies in the simulation befor t begin to drop under 60 fps and that is with 200 bodies constantly coliding with the generated ground, each other and the player controled unit it's quite impressive but i started facing tuneling issue they can come from my mesh or from bullet i need more testing to be sure