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