Bullet and ODE

[plok]

Firstly, I'd just like to say how nice the demos look...

Secondly, I'm currently writing a very simple proof of concept 3D engine. The rendering is homebrew, but I am currently using ODE for physics and collision detection. I was wondering how Bullet might play a part in the engine - only collision detection, or are you planning to add more features to make Bullet more like ODE? (e.g. joints)

[Erwin Coumans]

Hi,

It all depends, what you are looking for, but I would recommend to try to hook-up the Bullet collision detection to ODE.

Perhaps look at the module overview, or doxygen:
DOXYGEN:
http://www.continuousphysics.com/Bullet ... tated.html
MODULE OVERVIEW:
http://www.continuousphysics.com/ftp/pu ... odules.pdf
ODE has more joints, and motors, Bullet only has ball-socket so far. Also Bullet lacks some optimizations like a kdop-tree for triangle meshes.
Benefit of Bullet is the unified convex collision detection, swept convex cast (swepth sphere, box), time of impact, and more understandable source code.

Would you be interested to try out to connect them together ?
Erwin

[plok]

I'm not the greatest at maths/physics, but I'm quite good at gluing things together, so I will definitely give it a try. I get how ODE works, but I must admit to not understanding how Bullet works at all - I'll take a look next week...

[kfields]

Hi Erwin,

Thanks for sharing this code, I am also working on an engine using ODE and Ogre but I would really like to have continuous collision with convex support. I would also be interested in using Bullets dynamics once they mature a bit more, but for now I am primarily interested in using it for contact determination only.

I already have implemented a broadphase collision system and custom compound geoms. (I didn't like their implementation of spaces or geom transforms). At this point I could drop using ODE geom objects altogether I think.

All I need is a way to get contact points from bullet.

I've browsed through the source code and it looks like I would need to ...

1. Have a BroadphaseProxy member within my Geom/Shape wrapper class.

2. Implement a method similar to SimpleBroadphase::DispatchAllCollisionPairs, since, (no offense!), I would like to continue using my own broadphase.

3. Make the virtual call to CollisionAlgorithm::ProcessCollision.

4. Hmmmmm... after looking at ConvexConvexAlgorithm::ProcessCollision I see that it is tied directly to the dynamics part of bullet and that my reasoning is at a dead end.

I know this is a lot to ask but do you think you could separate the collision from the dynamics code? I think it would be beneficial to you as well.

I'm trying to think of a way to tease the two apart.

It could be as simple as having a function that returns a contact point array like ODE.

Or maybe by creating an interface called ContactProcessor that gets passed to ProcessCollision and have it implement a ProcessContacts function?

Code: Select all

class ContactProcessor {
public:
   int m_numContacts ;
   Result *p_results ;
   void ProcessContacts() ;
}

Only ... how do you do memory management for the Result object in that case? Wouldn't we want to reuse it and avoid creation and deletion overhead? That seems to imply that ContactProcessor creates and owns the Result object, only, I can see that you are using different Result classes created within the ProcessCollision function. I'm stuck.

I know this is pretty sloppy but It's the best I could do for tonight. Maybe I'll think of something better tomorrow.

Thanks again!

[Erwin Coumans]

All I need is a way to get contact points from bullet.

In that case, it is probably best to just use the collision detection, which is located in the /Bullet/Bullet folder. You don't need any of the dynamics or integration files (ConvexConvexCollisionAlgorithm).

All you need it calling gjk, and pass the

Code: Select all

PersistentManifold* m_manifoldPtr;

ManifoldResult output(body0,body1,m_manifoldPtr);
GjkPairDetector::ClosestPointInput input;
//init input
m_gjkPairDetector.GetClosestPoints(input,output);
//the PersistentManifold class automatically manages the contact points, ManifoldResult passes contact points it gets from GJK.

Persistency of the contacts is done by the PersistentManifold class, and you can manage their lifetime yourself. No dynamic allocation is required if you use a cache of PersistentManifolds.

I will have a look if it is doable to move ConvexConvexCollisionAlgorithm to the collision detection folder (it is a kind of bridge class at the moment). In that case you can use more of the framework.

By the way, can you share your broadphase ?

Thanks a lot for the feedback,
Erwin

[kfields]

Persistency of the contacts is done by the PersistentManifold class, and you can manage their lifetime yourself. No dynamic allocation is required if you use a cache of PersistentManifolds.

Sounds good!

I will have a look if it is doable to move ConvexConvexCollisionAlgorithm to the collision detection folder (it is a kind of bridge class at the moment). In that case you can use more of the framework.

Yeah, I was thinking in order to do that you would have to move the contact processing down into the shape classes, or create a two tier wrapper system like the one I have, and move it up.

By the way, can you share your broadphase ?

Sure, I've been putting off uploading this to SourceForge but maybe you could give me some feedback in return?

https://sourceforge.net/project/showfil ... _id=113759
http://www.botworx.org

Thanks Erwin!

Kurtis