Help! Integration of CD-library with bullet

Please don't post Bullet support questions here, use the above forums instead.
Frederick
Posts: 1
Joined: Wed Jun 13, 2007 8:36 am

Help! Integration of CD-library with bullet

Post by Frederick »

Hi =)

I am new to the board, so I will introduce me, first of all. I am a german
cs student. I have joined a one-year-lasting project group at my university. Our goal is the creation of a collision detection library.
It should support rigid body collision, deformable body collision and deformable body self-collision and should work together with common physics and graphics engines.

We have a website already, but there is not much till now =)
At the moment I care about the integration with physic engines. We have got a simple hash algorithm working for deformable objects.
You find the paper at the bottom of the page. Hopefully a bounding volume based algorithm will follow later.

The question is, how would you do or would you like the interface between
a cd-library and bullet ?
We have no practical experiences till now, and we really need a starting point.
How would we do a deformable cube for example ? Our tutor suggested the use of displacement fields.
So we would create 8 masses, for say the edges of the cube, connect them with springs. Then we would let bullet to the simulation, calculate the displacement vectors of the mass points from one frame to the next, we would do linear interpolation between the displacement vectors and apply the result to our meshes.

At the moment its a bit like stumbling through the dark, because we read paper after paper, but have no experience with all this.

How would you do such an integration ? We really appreciate your help, because the project is a bit above our heads at the moment
:?

Thanks a lot,
Frederick

P.S: Sorry couldn´t post links - because this is my first post ??? *lol* very strange
Dirk Gregorius
Posts: 861
Joined: Sun Jul 03, 2005 4:06 pm
Location: Kirkland, WA

Post by Dirk Gregorius »

Bullet is actually a CD library. So I strongly suggest looking at it, since it is the project that is the most active of all others. You can also look at other libraries, e.g. ODE. Here you could look how Opcode and GImpact are integrated. Then finally you could also look at Ageia. Ageia might be interesstin since they have some deformable objects support IIRC...


Cheers,
-Dirk

PS:
You can post links in your second post. This is to avoid spamming I guess
bone
Posts: 231
Joined: Tue Feb 20, 2007 4:56 pm

Post by bone »

Dirk Gregorius wrote:Bullet is actually a CD library.
Well it's both a CD library *and* a physics library. You can use one or the other or both.
Dirk Gregorius
Posts: 861
Joined: Sun Jul 03, 2005 4:06 pm
Location: Kirkland, WA

Post by Dirk Gregorius »

What I actually meant is Bullet is *also* a CD library not only a physic library :-)
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA

Post by Erwin Coumans »

There is one example of an external collision detection library integration, GIMPACT, into Bullet collision detection. See 'MovingConcaveDemo' for example.

In short: you can use BulletCollision without the BulletDynamics, but not easily the other way around. Bullet's main effort and focus has been into collision detection (see src/BulletCollision), less on the physics side (src/BulletPhysics).

Bullet collision detection has been designed in a way so that you can replace parts of the collision detection pipeline easily. For example, the broadphase collision detection (early culling based on axis aligned bounding box overlap) can be replaced by deriving your own class from btBroadphaseInterface. You can register your own narrowphase convex or concave collision detection algorithms to the collision dispatcher.

Unlike the collision detection, the small dynamics part (src/BulletPhysics) is tightly dependent on Bullet collision detection, so replacing Bullet entire collision detection from the dynamics is not easily possible. Bullet btDynamicsWorld derives from btCollisionWorld class, and the solver directly uses btPersistentManifold to retrieve the contacts. One of the reasons is to allow handling of continuous collision detection events (using a time-of-impact queue in the time-stepping loop. This feature was enabled in earlier versions of Bullet, but it is currently disabled. It will be re-enabled later this year)

It would be interesting to collaborate on deformable collision detection. Bullet has an optimized partiall re-fit of the AABB tree, which could be extended to support cloth and other deformable objects (tetrahedralization of deformable objects, and so on)

If your collision detection system is modular too, then inner algorithms could be plugged into Bullet collision detection. So this is more a software engineering decision. For example, Bullet collision detection has reusable parts (like GJK) that don't rely on the framework (See Bullet/Demos/CollisionDemo, it uses GJK but it doesn't rely on btCollisionWorld framework). If you design your system in a simular way, so that the reusable parts (cloth self collision for example) don't rely on your framework that would be perfect.

Thanks,
Erwin