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)
Bullet and ODE
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
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
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
-
- Posts: 2
- Joined: Sat Jul 30, 2005 11:12 am
-
- Posts: 2
- Joined: Fri Jul 22, 2005 11:49 pm
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?
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!
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() ;
}
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!
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
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).kfields wrote: All I need is a way to get contact points from bullet.
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.
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
-
- Posts: 2
- Joined: Fri Jul 22, 2005 11:49 pm
Sounds good!Erwin Coumans wrote: 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.
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.Erwin Coumans wrote: 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.
Sure, I've been putting off uploading this to SourceForge but maybe you could give me some feedback in return?Erwin Coumans wrote: By the way, can you share your broadphase ?
https://sourceforge.net/project/showfil ... _id=113759
http://www.botworx.org
Thanks Erwin!
Kurtis