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
Help! Integration of CD-library with bullet
-
- Posts: 861
- Joined: Sun Jul 03, 2005 4:06 pm
- Location: Kirkland, WA
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
Cheers,
-Dirk
PS:
You can post links in your second post. This is to avoid spamming I guess
-
- Posts: 231
- Joined: Tue Feb 20, 2007 4:56 pm
-
- Posts: 861
- Joined: Sun Jul 03, 2005 4:06 pm
- Location: Kirkland, WA
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
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
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