Physics Simulation Forum

I'd like to transition from using an intrinsic collision system to Bullet. Currently, one great benefit to the intrinsic collision system that was written for my engine is the fact that since there is tile data, I can quickly walk across the lines of polygons and quickly check if they're within cubes inside a 3D grid in the level. For doing ray tracing as well, it's quite quick.

Is there an alternative? Should I really create thousands of boxes for each collision tile?

Of course not. You'll have to somehow approximate it. Ideally, each tile might be built out of a few btRigidBody instances. Or perhaps a single btRigidBody from a compound shape.
I cannot quite see any reason to create "thousands" of boxes for each tile. What would be the point? What is a tile for you? Would you elaborate?

Sorry, I don't think that's what I'm referring to.

I meant, for the entire map, beyond characters/vehicles/etc..., there's tile data. Obstacles are represented by cubes of tiles that are consistently the same size. Would I really make an instance of all collision tiles? That is, say I had a large labyrinth, which means there'd be thousand of wall tiles, would the best approach be to create a bunch of boxes? Or is there some trick for something like this, similar to a heightfield, that works on a very large scale of rectangles that spans an entire level?

I see. There are a few options.

First, probably simplest, is to just create a few boxes. A thousand of static boxes or simple hulls can probably be mangled at reasonable speed. My current world is about 400 boxes and 200 hulls, ticks at about 100 fps on my system (Athlon X3 450).

The next step would be to collapse nearby boxes in a single one. This will also improve stability.

Note, as showed here bullet silently assumes rigid bodies do not touch each other. When this does not hold true, there will be issues with simulation stability (although predictability is probably a better term).

To solve this, I have played a bit with polygon soups (they allow internal edges to be properly detected)... I couldn't quite make them work, in general, I think the best thing to do is to have a proper kinematic controller taking care of those cases. As for dynamics... well, I guess that's a problem.

I wonder if it's worth implementing a new type of object, rather than fighting with the system. If everything is aligned and consistently sized. I'm sure others could benefit from this special object as well.

I, of course, agree that I could collapse boxes and whatnot, but when changing the environment at run-time, it could prove to be tedious.

The default broadphase is using a dynamic tree for each group of bodies and therefor the lookup cost for small dynamic bodies is only O(log n) where n is the number of static bodies. My game use thousands of static bodies without any problem.