Ogre & Bullet

Show what you made with Bullet Physics SDK: Games, Demos, Integrations with a graphics engine, modeler or any other application
tuan kuranes
Posts: 10
Joined: Mon Sep 04, 2006 1:40 pm
Location: Grenoble, France

Ogre & Bullet

Post by tuan kuranes »

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
User avatar
Erwin Coumans
Site Admin
Posts: 4236
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Ogre & Bullet

Post by Erwin Coumans »

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
We should definately collaborate, and I can offer some support, if you post here on the forum.

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
snailrose
Posts: 15
Joined: Sun May 28, 2006 6:44 pm

Post by snailrose »

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
tuan kuranes
Posts: 10
Joined: Mon Sep 04, 2006 1:40 pm
Location: Grenoble, France

Post by tuan kuranes »

Thanks for answers, code and pointers.

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.
User avatar
Erwin Coumans
Site Admin
Posts: 4236
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Post by Erwin Coumans »

Thanks Tuan,

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".
- 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

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 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.

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)
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).

Code: Select all

Demos
--------
- same kind as ogreode : vehicle, terrains, stacking, constraints, ragdolls...
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).
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.
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.
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.
In that case, I would recommend just using bt* C++ classes, no wrapper.
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.
tuan kuranes
Posts: 10
Joined: Mon Sep 04, 2006 1:40 pm
Location: Grenoble, France

Post by tuan kuranes »

Thanks for the very detailed and interesting answer and support.
I'll have a deep look in that and start a first design version then.
User avatar
jacmoe
Posts: 9
Joined: Fri Aug 05, 2005 2:59 pm

Post by jacmoe »

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 ... :wink:

Since I am not targeting physics, but pure collision detection..

Looking forward to seeing what you guys come up with.
User avatar
detox
Posts: 12
Joined: Wed Nov 22, 2006 6:52 pm
Location: Ohio, USA
Contact:

Post by detox »

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.

Image

Image
tuan kuranes
Posts: 10
Joined: Mon Sep 04, 2006 1:40 pm
Location: Grenoble, France

Post by tuan kuranes »

@ 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.
I would love to get my hands on a .blender parser or a Collada setup to load scene + physics data into Ogre.
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.
User avatar
detox
Posts: 12
Joined: Wed Nov 22, 2006 6:52 pm
Location: Ohio, USA
Contact:

Post by detox »

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.
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!

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.
User avatar
jacmoe
Posts: 9
Joined: Fri Aug 05, 2005 2:59 pm

Post by jacmoe »

tuan kuranes wrote:@ 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 ?
I think so! :)
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! :P ).

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. :)
syedhs
Posts: 1
Joined: Fri Dec 08, 2006 5:42 pm

Post by syedhs »

detox, tuan, jacmoe & snailrose,

Way to go! I just registered my nick here to give moral support.. lets us see another physics wrapper for our Ogre :lol:
User avatar
jacmoe
Posts: 9
Joined: Fri Aug 05, 2005 2:59 pm

Post by jacmoe »

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.
Well, it doesn't work for collision detection only.
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. :wink:

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

<edit Thanks, syedhs! :lol: />
snailrose
Posts: 15
Joined: Sun May 28, 2006 6:44 pm

Post by snailrose »

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:

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();

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
tuan kuranes
Posts: 10
Joined: Mon Sep 04, 2006 1:40 pm
Location: Grenoble, France

Post by tuan kuranes »

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

Code: Select all

 btrigigbody::setLinearVelocity(btVector3) 
and

Code: Select all

 btrigigbody::setLinearVelocity(x,y,z)
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
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
@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.

@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...
Post Reply