Planetary scale collision & physics

User avatar
JohnJ
Posts: 9
Joined: Tue Feb 26, 2008 6:24 pm
Location: California

Planetary scale collision & physics

Post by JohnJ »

I'm working on a game engine that will be handling huge planetary (spherical) worlds. The rendering part is already solved for the most part, and now I'm at the stage where I need to choose a physics engine. Bullet is my first choice due to many of its advantages and features, but I'd like to get some opinions on this matter:

Is Bullet capable of paging custom collision data in and out of memory fairly efficiently? Are there any special features or options that I should be aware of that will help in dynamically paging 3D grid-style collision data?

Thanks :)
Laser
Posts: 1
Joined: Thu Feb 28, 2008 11:11 am

Re: Planetary scale collision & physics

Post by Laser »

I am also interested in this, in the future (using as graphical interface OSG or perhaps Ogre (depends on JohnJ or Tuan :D ) )
I only read about Bullet in these forums, and skimmed through some examples so what i ask is newbish: for a paged/large solution (more than 10Kmeters square), how can one set the AABBs bounds for the dynamic worlds, or can that bounds be updated? Or my question makes no sense :) ?

Regards,
Laser
User avatar
JohnJ
Posts: 9
Joined: Tue Feb 26, 2008 6:24 pm
Location: California

Re: Planetary scale collision & physics

Post by JohnJ »

No suggestions?

That's ok I guess, I suppose I'll just research it myself :?
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA

Re: Planetary scale collision & physics

Post by Erwin Coumans »

How many objects do you expect in your universe? How are they distributed?

You should be able to write your own broadphase, and hook it up to Bullet fairly easy.

There is already an work-in-progress implementation for huge worlds in
src\BulletCollision\BroadphaseCollision\btMultiSapBroadphase.h
You can track progress in Google Code Issue list here:
http://code.google.com/p/bullet/issues/detail?id=21

The idea is to allow the user/developer to combine/add multiple broadphases, that all add overlapping pairs to a common overlapping pair array. Removal of pairs should be postponed until pair processing, so you need to comment out 'USE_HASH_PAIRCACHE' in
src\BulletCollision\BroadphaseCollision\btOverlappingPairCache.h

Hope this helps,
Erwin
User avatar
JohnJ
Posts: 9
Joined: Tue Feb 26, 2008 6:24 pm
Location: California

Re: Planetary scale collision & physics

Post by JohnJ »

Thanks for reply :)
How many objects do you expect in your universe? How are they distributed?
Planets are loaded centered around (0, 0, 0). They are fairly large (6x4096x4096 vertices without LOD), and I don't expect to be able to load everything on one planet at once (although the collision shapes of various objects can be pre-loaded).

My only concern is with the terrain - with 6x4096x4096 vertices (>100,000,000) it's obvious that I'm going to need to page the data in and out of the collision system (the rendered geometry is paged, obviously). I know very little about collision detection implementations, but I assume you have to do a certain amount of preprocessing before you can add a new collision shape. I was wondering if Bullet provides any methods for adding heightfield-style collision shapes to the scene fairly efficiently.

I'll look into implementing a custom broadphase, although it may not be necessary since not that many objects are going to be loaded at any time.

BTW, I'll eventually research this all myself when I get to that stage, so there's actually no real rush in solving these problems. I just thought I'd post because it'd be nice to know where to begin when I do start work on the physics integration (which won't be too long from now).

I should also mention that I'm completely new to Bullet (I recently decided to switch from PhysX), and haven't used it in any projects at all before. I don't know much about Bullet, but it seems to be very highly regarded by many developers, and I like the look of the API so far - if it works out in our project I think I'll be very happy using it :)