Hi fellow developers!

I'm currently developing a small game prototype based on some well known "cube game". I use PolyVox to manage voxels and Ogre3d for the graphics.

After having tried to code my own physics component using PolyVox's Raycasts and having failed poorly due to my lack of skill in this domain (thus not having completely abandoned the idea) I have decided to use an external library.

Anyway, I have an 32x128x32 Material8 volume (extracted using CubicSurfaceExtractor & Decimated (nice, by the way!)) that I would like to make known to Bullet, but how should I do that ?

I tried using the btBoxShape but it was way too slow and I feel it's wrong since the cube faces that are not visible should not the used by Bullet. I recently saw the btCompoundShape but got no time to test it.

I also tried using the btBvhTriangleMeshShape with the BulletMeshStrider (http://www.ogre3d.org/tikiwiki/BulletMe ... e=Cookbook), but when I add it to Bullet it crashes when the first collision occurs. I'm probably doing someting wrong.

So, has someone successfully "declared" a volume to Bullet ? How to do that efficiently ? I saw no reference to Bullet in Thermite and found no piece of code showing how to do that.

you can look at foreverwar (find it on sourceforge or in this forum)
the extracted meshes are passed to bullet, which might be a little overkill for your case, but it would allow for later changes like if you add 45degree parts or anything else non cubical.

Ok, here's what I can tell you. I did use Bullet physics for the rigid body demo which you can download here:

http://www.thermite3d.org/releases/ThermitePhysicsDemo.zip

However, I don't have a source archive corresponding to that release, and I don't use Bullet in Thermite any more (but it will probably come back in the future). But according to this post I released the demo in April 2008, so if you get the SVN version corresponding to that date then you should find the Bullet code in there.

It's probably too hard to try and build it, but you may be able to look in the code to see what I was doing. As I recall I made use of a standard Bullet mesh (maybe this was the btBvhTriangleMeshShape?). Actually I had a number of these corresponding to different parts of the volume, so that when the volume changed I didn't have to update the whole thing.

I recall that a limitation was that I couldn't have interaction between two concave objects, so the rigid bodies had to be convex. It's also worth noting that I was using the OgreBullet wrapper for this, though next time I'd probably just implement it myself.

As for the crash I can't help you, you'll need to look in the debugger.

I'm using OgreBullet. The way I'm doing it is pretty simple at the moment. I have a "view" class corresponding to a volume mesh which I extract from a Volume. My view class converts the mesh object from polyvox into a Ogre manual object. I then use a physics manager (a wrapper of OgreBullet) to convert the Manual object into a TrimeshCollision shape, which is then added to a STATIC rigid body. It's been working decently for me and I'm not going to touch it for now.

I use it for ray detection against my volume, because I figure since it's there why not use it.

BUT, I was thinking whether it is possible to have a custom call-back dispatch from Bullet so I don't have to create the Mesh in Bullet and instead simply have Bullet call the Volume class for collision against the Volume. I figure there has to be a way to do this. This is perfect because it will eliminate the need for a look up structure on Bullet's side (I bet it's more efficient due to the uniform nature; well, I'm also using the BVH for broadphase) plus memory savings.

BTW the memory savings would be phenomenal if I eliminated the Bullet mesh. Right now I use A LOT of memory for storing the mesh in Bullet. This is cmopletely unncessary and stupid.

Yes, it would be very interesting to test directly against the underlying volume rather than the mesh. Bullet already has a heightfield shape which I assume does something similar though I haven't looked into it. I'd imagine it was possible to get at least the collision detection working with this approach, but I'm not so sure about the collision response. Do let us know if you ever get it working.

Thanks everyone, I will try using these examples.



Yes, this would be perfect!