Ogre & Bullet
-
- Posts: 10
- Joined: Mon Sep 04, 2006 1:40 pm
- Location: Grenoble, France
Ogre & Bullet
I want to build a "OgreBullet" wrapper that would help Ogre users use Bullet, along with a few Demos.
Exaclty like what OgreOde does.
I've Heard Next Blender-Bullet Real-time display would use Ogre... I hope o find a way so gather efforts on that.
I'm interested on any Ogre - Bullet demos/integration/information/code
Exaclty like what OgreOde does.
I've Heard Next Blender-Bullet Real-time display would use Ogre... I hope o find a way so gather efforts on that.
I'm interested on any Ogre - Bullet demos/integration/information/code
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Ogre & Bullet
We should definately collaborate, and I can offer some support, if you post here on the forum.tuan kuranes wrote:I want to build a "OgreBullet" wrapper that would help Ogre users use Bullet, along with a few Demos.
Exaclty like what OgreOde does.
I've Heard Next Blender-Bullet Real-time display would use Ogre... I hope o find a way so gather efforts on that.
I'm interested on any Ogre - Bullet demos/integration/information/code
The 'PRO Ogre 3D programming' book is here on the table...
I will ask Charlie/snailrose, to reply on this topic. He has been doing integration with with Ogre, Blender and Bullet (and some COLLADA I think).
Thanks,
Erwin
-
- Posts: 15
- Joined: Sun May 28, 2006 6:44 pm
Hey Guys,
I'm willing to combine efforts, or collaborate on any Bullet/Blender/Ogre project.
You can find the Blender "echo-plugin" project page here:
http://sourceforge.net/projects/echo-plugin
Which is simply a test app that converts basic COLLADA and Blender data to Ogre at runtime.
Here is a small demo using Bullet and Ogre, Its split into source/binary downloads. Space bar adds new cubes....
http://www.continuousphysics.com/ftp/pu ... estBin.zip
http://www.continuousphysics.com/ftp/pu ... estSrc.zip
Thanks,
Charlie
I'm willing to combine efforts, or collaborate on any Bullet/Blender/Ogre project.
You can find the Blender "echo-plugin" project page here:
http://sourceforge.net/projects/echo-plugin
Which is simply a test app that converts basic COLLADA and Blender data to Ogre at runtime.
Here is a small demo using Bullet and Ogre, Its split into source/binary downloads. Space bar adds new cubes....
http://www.continuousphysics.com/ftp/pu ... estBin.zip
http://www.continuousphysics.com/ftp/pu ... estSrc.zip
Thanks,
Charlie
-
- Posts: 10
- Joined: Mon Sep 04, 2006 1:40 pm
- Location: Grenoble, France
Thanks for answers, code and pointers.
Here's my current todo:
Obviously, Scene builder and Mesh2Physic will share some code with Echo-plugin.. maybe that would be possible to make a OgreBullet Demo that reads .blend (or using/enhancing a .blend exporter ) and do render them in OgreBullet.
I still hesitate wheter an "overall" wrapper around Bullet class (so that user never use a "bt*" class ) like "OgreOde" does or much like snailrose demoed in source above, just some utils class to help Ogre-Bullet interaction.
@erwin: I would if possible avoid using a C interface of Bullet and rather use C++ directly, just because C++ is much more readeable from my pov. (IMHO C-interface lowers contributions as it hides internals too well.) But If you think the wrapper/utils should be build around a C-interface I'll wait for that.
Here's my current todo:
Code: Select all
Utils Class :
-------------
- Utils that makes an Ogre Mesh a "Convex", "TriangleMesh", etc...
- Utils that make disabled/sleeping object a static geometries ( ie: making dynamically the whole set of bricks composing a "sleeping wall" a single Vertex Buffer, much faster rendering than each brick rendered each along, overcoming the "GPU-CPU batching problem".
Debug Class :
-------------
- Some Visual Debug gui (normals, contact points, forces, etc...)
- Some gui to tweaks physics variables real time.
- Have a pause/stop/play/faster/lower button
Tools
------
- Scene builder (load mesh, add physic properties, add some scene realtive infromation) that can export both in collada or a binary Ogre/Bullet oriented format.
- Mesh2Physic tool (Tweak Convex decomposition, and add physic properties)
Demos
--------
- same kind as ogreode : vehicle, terrains, stacking, constraints, ragdolls...
Obviously, Scene builder and Mesh2Physic will share some code with Echo-plugin.. maybe that would be possible to make a OgreBullet Demo that reads .blend (or using/enhancing a .blend exporter ) and do render them in OgreBullet.
I still hesitate wheter an "overall" wrapper around Bullet class (so that user never use a "bt*" class ) like "OgreOde" does or much like snailrose demoed in source above, just some utils class to help Ogre-Bullet interaction.
@erwin: I would if possible avoid using a C interface of Bullet and rather use C++ directly, just because C++ is much more readeable from my pov. (IMHO C-interface lowers contributions as it hides internals too well.) But If you think the wrapper/utils should be build around a C-interface I'll wait for that.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Thanks Tuan,
Here some quick remarks/hints:
- There are 2 possible approaches with convex/triangle mesh: either duplicating, or sharing the graphics/physics mesh using indexing/striding. Duplicating is easier to start with.
- Moving concave meshes are preferably decomposed into convex pieces, as btConvexHullShape, and added to a compound shape, btCompoundShape. You can use CreateDynamics tool, or manually create the pieces. But you can also register the optional GIMPACT concave mesh into the dispatcher's Collision Matrix . See Bullet/Demos/MovingConcaveDemo how to do this. This requires registration of btConcaveConcaveCollision algorithm and linking 2 libraries that are included in Bullet/Extras/GIMPACT and Bullet/Extras/GIMPACTBullet integration. You can use GIMPACT ZLib license, same as Bullet.
- btRigidBody::setActivationState is useful for (de)activation/sleep
- For debug, you can derive from btIDebugDrawer, that handles feedback/rendering of contact points, AABB's, simplified collision shapes rendering etc. If things are missing from the btIDebugDrawer functionality, please let me know.
- for pauze/stop/play/faster/lower, you can use the stepSimulation interface, together with built-in interpolation. Passing a smaller timestep then 1.60 (default) will automatically interpolate, larger will increase the number of internal substeps (up to a maximum). See CcdPhysicsDemo, press 'i' to pause, and press 's' to single step. In the console it tells wether an interpolation step or simulation step is performed.
You can use CreateDynamics tool for automatic convex decomposition, and ragdoll creation and export to COLLADA physics. Blender should be able to assign physics properties. I also plan providing a basic editor for Bullet/COLLADA physics to do such task (in MFC, and perhaps a OS X version).
Bullet has a built-in vehicle. terrains require a custom shape, should be doable (there is some thread about this and an example is upcoming). constraints ragdolls are possible, but notice that the btGeneric6DOF constraint is work in progress (motors, more robust, and better/additional cone limits).
One of the upcoming steps in Bullet is adding SIMD support, so no direct cast from Ogre 3D Vector3 to btVector3. So it's best to keep using the btMotionState interface to synchronize world transforms, as Charlie demonstrated, instead of getting world transform/position directly from the btRigidBody. This helps with interpolation, as the rigidbody only has the simulated state, not the interpolated.
Your plans sounds all excellent! Note that Bullet is under active development, so just report issue here so we can handle them.
Thanks,
Erwin
Here some quick remarks/hints:
Code: Select all
Utils Class :
-------------
- Utils that makes an Ogre Mesh a "Convex", "TriangleMesh", etc...
- Utils that make disabled/sleeping object a static geometries ( ie: making dynamically the whole set of bricks composing a "sleeping wall" a single Vertex Buffer, much faster rendering than each brick rendered each along, overcoming the "GPU-CPU batching problem".
- Moving concave meshes are preferably decomposed into convex pieces, as btConvexHullShape, and added to a compound shape, btCompoundShape. You can use CreateDynamics tool, or manually create the pieces. But you can also register the optional GIMPACT concave mesh into the dispatcher's Collision Matrix . See Bullet/Demos/MovingConcaveDemo how to do this. This requires registration of btConcaveConcaveCollision algorithm and linking 2 libraries that are included in Bullet/Extras/GIMPACT and Bullet/Extras/GIMPACTBullet integration. You can use GIMPACT ZLib license, same as Bullet.
- btRigidBody::setActivationState is useful for (de)activation/sleep
Code: Select all
Debug Class :
-------------
- Some Visual Debug gui (normals, contact points, forces, etc...)
- Some gui to tweaks physics variables real time.
- Have a pause/stop/play/faster/lower button
- for pauze/stop/play/faster/lower, you can use the stepSimulation interface, together with built-in interpolation. Passing a smaller timestep then 1.60 (default) will automatically interpolate, larger will increase the number of internal substeps (up to a maximum). See CcdPhysicsDemo, press 'i' to pause, and press 's' to single step. In the console it tells wether an interpolation step or simulation step is performed.
Code: Select all
Tools
------
- Scene builder (load mesh, add physic properties, add some scene realtive infromation) that can export both in collada or a binary Ogre/Bullet oriented format.
- Mesh2Physic tool (Tweak Convex decomposition, and add physic properties)
Code: Select all
Demos
--------
- same kind as ogreode : vehicle, terrains, stacking, constraints, ragdolls...
Either reading a .blend or exporting should be fine indeed. Charlie has experimented with blend2cs to import data from a .blend I think. Notice that Blender COLLADA export includes physics info (except constraints, which is on the todo list, it is exposed to Python scripting). CreateDynamics uses a tiny xml approach, which is less bloated then using COLLADA-DOM+libxml.Obviously, Scene builder and Mesh2Physic will share some code with Echo-plugin.. maybe that would be possible to make a OgreBullet Demo that reads .blend (or using/enhancing a .blend exporter ) and do render them in OgreBullet.
In that case, I would recommend just using bt* C++ classes, no wrapper.I still hesitate wheter an "overall" wrapper around Bullet class (so that user never use a "bt*" class ) like "OgreOde" does or much like snailrose demoed in source above, just some utils class to help Ogre-Bullet interaction.
@erwin: I would if possible avoid using a C interface of Bullet and rather use C++ directly, just because C++ is much more readeable from my pov. (IMHO C-interface lowers contributions as it hides internals too well.) But If you think the wrapper/utils should be build around a C-interface I'll wait for that.
One of the upcoming steps in Bullet is adding SIMD support, so no direct cast from Ogre 3D Vector3 to btVector3. So it's best to keep using the btMotionState interface to synchronize world transforms, as Charlie demonstrated, instead of getting world transform/position directly from the btRigidBody. This helps with interpolation, as the rigidbody only has the simulated state, not the interpolated.
Your plans sounds all excellent! Note that Bullet is under active development, so just report issue here so we can handle them.
Thanks,
Erwin
Last edited by Erwin Coumans on Thu Dec 07, 2006 5:17 pm, edited 1 time in total.
-
- Posts: 10
- Joined: Mon Sep 04, 2006 1:40 pm
- Location: Grenoble, France
-
- Posts: 9
- Joined: Fri Aug 05, 2005 2:59 pm
Hi, tuan! 
Looks like you beat me to OgreBullet.
I had it all setup on my SVN some time ago, and wanted it to be the successor of OgreOpcode.
I hacked up the first tentative Ogre collision test a couple days ago.
Well, well ...
Since I am not targeting physics, but pure collision detection..
Looking forward to seeing what you guys come up with.

Looks like you beat me to OgreBullet.
I had it all setup on my SVN some time ago, and wanted it to be the successor of OgreOpcode.
I hacked up the first tentative Ogre collision test a couple days ago.
Well, well ...

Since I am not targeting physics, but pure collision detection..
Looking forward to seeing what you guys come up with.
-
- Posts: 12
- Joined: Wed Nov 22, 2006 6:52 pm
- Location: Ohio, USA
http://home.woh.rr.com/abyss/bulletogre_src.zip
I too have been working on a Bullet + Ogre combination. I have something reasonable working with static meshes, boxes, and spheres. Convex decomposition is in the works and turning out pretty well - based around the demo distributed with Bullet.
The bits of my code that you may find useful are the Ogre mesh -> Bullet static triangles collision object routine and the routine which calculates a tight bounding box size based on an Ogre mesh.
I would love to get my hands on a .blender parser or a Collada setup to load scene + physics data into Ogre. Right now I use my own heavily modified .scene XML file parser routine based on the article in the Ogre Wiki. It's a mess but it works.
Please, please, if you look over my code keep in mind I am not a trained coder, I have never taken a programming class, I just do this for fun! ..and sometimes a quick util or two for work. Constructive feedback is more than welcome though.
Here's a screenshot or two from my Blender -> Ogre + Bullet test bed. I'll post complete src, binaries, and data if anyone thinks it would be worth while.


I too have been working on a Bullet + Ogre combination. I have something reasonable working with static meshes, boxes, and spheres. Convex decomposition is in the works and turning out pretty well - based around the demo distributed with Bullet.
The bits of my code that you may find useful are the Ogre mesh -> Bullet static triangles collision object routine and the routine which calculates a tight bounding box size based on an Ogre mesh.
I would love to get my hands on a .blender parser or a Collada setup to load scene + physics data into Ogre. Right now I use my own heavily modified .scene XML file parser routine based on the article in the Ogre Wiki. It's a mess but it works.
Please, please, if you look over my code keep in mind I am not a trained coder, I have never taken a programming class, I just do this for fun! ..and sometimes a quick util or two for work. Constructive feedback is more than welcome though.
Here's a screenshot or two from my Blender -> Ogre + Bullet test bed. I'll post complete src, binaries, and data if anyone thinks it would be worth while.


-
- Posts: 10
- Joined: Mon Sep 04, 2006 1:40 pm
- Location: Grenoble, France
@ jacmoe : Sorry
Anyway, you raise a good point. I'm thinking on on having same Bullet separation collision between and dynamics in OgreBullet. So At least 2 core lib OgreBulletCollision, OgreBulletDynamics.
That seems to make sense to me. Does it ?
@detox : I'll be interested by any source that helps me think about design, as it can help see limitations/pros/cons.

That seems to make sense to me. Does it ?
@detox : I'll be interested by any source that helps me think about design, as it can help see limitations/pros/cons.
Then check that with "echo_plugin" source snailrose posted above. We really have to find a way to make that things working, since prototyping/editing/scening/tweaking with blender and then using it in Ogre seems a great Idea.I would love to get my hands on a .blender parser or a Collada setup to load scene + physics data into Ogre.
-
- Posts: 12
- Joined: Wed Nov 22, 2006 6:52 pm
- Location: Ohio, USA
Thanks! I missed that link the first time through. I agree, prototyping in Blender and then importing into Ogre would be ideal. I just saw a post about Blender 2.43 which will include a nice GUI for setting up the Bullet 6 degrees of freedom constraint without any Python scripting. Excellent!Then check that with "echo_plugin" source snailrose posted above. We really have to find a way to make that things working, since prototyping/editing/scening/tweaking with blender and then using it in Ogre seems a great Idea.
I looked through Snailrose's echo_plugin. I think this is the right way to go. The Blender Collada exporter support physics, and getting a Collada file into Ogre with the gfx and physics details all in one place just makes sense. This would make it very easy for me to use my serializer routine to dump the gfx and physics info together into my game's binary file format. I will atempt to help out where I can.
-
- Posts: 9
- Joined: Fri Aug 05, 2005 2:59 pm
I think so!tuan kuranes wrote:@ jacmoe : SorryAnyway, you raise a good point. I'm thinking on on having same Bullet separation collision between and dynamics in OgreBullet. So At least 2 core lib OgreBulletCollision, OgreBulletDynamics.
That seems to make sense to me. Does it ?

My plan was to first create a collision only base library.
Then the user could opt to use the addon physics library, to turn their collision shapes physical.
Of course, without changing exsisting code, but adding to it.
Looks like I have to rethink, and go program OgreSteer instead (unless you've already beaten me to that!

What I do have, however, is SVN space and forum space, should you want to use it for OgreBullet.
I already have some people interested in a collision only library..

Let me know if you're interested, or perhaps you prefer a home @ ogreaddons and Addons Forum?
OgreOpcode will tell you where a collision happened, but it doesn't do continuous collision detection, nor does it calculate penetration or even decent SAP.
So I decided to not reinvent any wheels, and go Bullet.

-
- Posts: 1
- Joined: Fri Dec 08, 2006 5:42 pm
-
- Posts: 9
- Joined: Fri Aug 05, 2005 2:59 pm
Well, it doesn't work for collision detection only.Erwin Coumans wrote:- For debug, you can derive from btIDebugDrawer, that handles feedback/rendering of contact points, AABB's, simplified collision shapes rendering etc. If things are missing from the btIDebugDrawer functionality, please let me know.
The debugdrawer is simply not called by any collision detection code, only during the physics related stepSimulation. (AFAIK).
That's not a problem, because it's easy to do, using Ogre.

The ability to automatically create simplified convex collision shapes from Ogre meshes.. Wow!

<edit Thanks, syedhs!

-
- Posts: 15
- Joined: Sun May 28, 2006 6:44 pm
Hey all,
Yeah echo contains a small conversion library that converts COLLADA/Blender data Ogre
When I figure out how to resolve pointers in a .blend. It can be expanded to parse blend files as well!
Only basic stuff is converted atm. Partial nodes (camera/mesh/empty) and basic physics.
It is heavily dependent on the echo project source to convert the data To Ogre.
But can be modeled away from that with out to much extra work if needs be.
For COLLADA:
The etScene just houses wrappers for Ogre objects.
Have a look at etOgreMesh.cpp and etOgreRigidBody.cpp for dt conversion to Ogre.
I would like to know how efficient/inefficient this library is towards your needs.
It would be simpler to flat out convert the objects without this library. But this way
there is a unified conversion from COLLADA/Blender/.blend -> OGRE
Thanks,
Charlie
Yeah echo contains a small conversion library that converts COLLADA/Blender data Ogre
When I figure out how to resolve pointers in a .blend. It can be expanded to parse blend files as well!
Only basic stuff is converted atm. Partial nodes (camera/mesh/empty) and basic physics.
It is heavily dependent on the echo project source to convert the data To Ogre.
But can be modeled away from that with out to much extra work if needs be.
For COLLADA:
Code: Select all
ColladaDOMLoader::createLoader();
ColladaDOMLoader *loader = ColladaDOMLoader::getSingletonPtr();
dtLibrary *lib = loader->load(daeFile);
dtSceneMap *sceneMap = lib->getSceneMap();
for (dtSceneMap::iterator scenes = sceneMap->begin(); scenes!=sceneMap->end(); ++scenes)
{
dtScene *convertedScene = scenes->second;
// handle Ogre Scene
etScene *scene = sceneContainer->createScene(convertedScene->getName());
// parse scene Objects
fillScene(convertedScene, scene);
// parse Physics
fillPhysics(convertedScene, scene);
}
loader->unload(daeFile);
ColladaDOMLoader::destroyLoader();
Have a look at etOgreMesh.cpp and etOgreRigidBody.cpp for dt conversion to Ogre.
I would like to know how efficient/inefficient this library is towards your needs.
It would be simpler to flat out convert the objects without this library. But this way
there is a unified conversion from COLLADA/Blender/.blend -> OGRE
Thanks,
Charlie
-
- Posts: 10
- Joined: Mon Sep 04, 2006 1:40 pm
- Location: Grenoble, France
I'm going toward inheritance wrapper instead of encapsulation wrapper.
@erwin :
- Is there or can we have a "svn-commit" mailing list ?
- As I'd like to know if you intend to add non-btvector3, btquaternion methods :
Idea would be to have both
and
the latter would be usable directly from Ogre code ?
As I have to make new getter anyway, it's certainly not mandatory in Bullet core Code, but may help other "wrappers" or even c-physic interface
@jacmoe : I'll go for ogreaddons if I can, just to centralize my addons administration. And no, OgreSteer is not planned
but in a far away time OgreAI is...
@erwin :
- Is there or can we have a "svn-commit" mailing list ?
- As I'd like to know if you intend to add non-btvector3, btquaternion methods :
Idea would be to have both
Code: Select all
btrigigbody::setLinearVelocity(btVector3)
Code: Select all
btrigigbody::setLinearVelocity(x,y,z)
As I have to make new getter anyway, it's certainly not mandatory in Bullet core Code, but may help other "wrappers" or even c-physic interface
@snailrose: if we don't loose any information between blender collada export and bullet-ogre collada import, then Collada medium is ok. Otherwise, .blend medium has to be used.It would be simpler to flat out convert the objects without this library. But this way
there is a unified conversion from COLLADA/Blender/.blend -> OGRE
@jacmoe : I'll go for ogreaddons if I can, just to centralize my addons administration. And no, OgreSteer is not planned
