I think it would be good to support multi-material meshes. There are use cases, for example a static terrain with different surfaces (slippery, mud, pavement, …). Splitting one mesh into several meshes each with one friction/restitution value is not a good solution. Besides performance there will be problems with those regions where one mesh ends and the other starts. Objects won’t slide perfectly smooth over such edges, no matter how good the vertices are alligned.
This means: yes, we have a missing feature here, and we should fill the gap - somehow.
For the static/dynamic triangle meshes: here is a link to the Bullet docs for the base class of all collision shapes. It shows the inheritance tree. for dynamic triangle meshes we use the btGImpactMeshShape, and for static meshes we use the btBvhTriangleMeshShape. The later has one derived class, the btMultimaterialTriangleMeshShape, which is the only one using btMaterials. No problem here. The only thing I am worried about is how to define the material/triangle mapping on the user interface side.
EDIT: forgot the link: continuousphysics.com/Bullet … Shape.html
Bach when I wrote the Bullet wrappers I though it would be clever to provide a low-level interface for creating collision meshes (via BulletTriangleMesh.add_triangle) and a high level convenience method (just pass a Geom, and I try to iterate over all triangles inside and add them automatically). The high level interface has been intended as a quick-and-dirty way for rapid prototyping. For real content the collision mesh should be less detailed than the render mesh.
This sooner or later boild down to content pipeline questions. And this is where you have done great work for Panda3D by writing your Blender exporter.
Currently I think that all physics modules should have a common way to provide content to them. Otherwise we would end up with exporter modules for Blender/Max/Maya… which need to implement different code for different physics engines (not clever). And there is already a standard for defining collision geometry in Panda3D, which is somehow controlable from EGG files. After importing an EGG file with collisions in Panda3D we have CollisionSolids in our scene graph. So currently I think Bullet should start here, with CollisionSolids, and convert them to it’s own collision geometry.
So here is the question to you: how would you export the material properties from Blender using the current EGG syntax?
If we can find a way here I’m sure we can find ways to define other physics properties too, like mass of an object. And once Bullet can pick up there information we would have a much better physics module.