Questions about the usage of triangle meshes in Bullet

[B_old]

Hi everybody,

I have a few question about the usage of triangle meshes in bullet.

1. btTriangleIndexVertexArray can hold several indexed meshes. How do I decide whether I put one large indexed mesh inside or rather several smaller ones. One specific reason I'm asking is, that parts of my static world geometry are partitioned into sub-meshes according to a AABB-tree. Now I could add those sub-meshes to bullet or create on big mesh and add it to bullet. AFAIK bullet will try to partition the mesh itself. Is it more efficient if it has one big mesh to work on?

2. Do I understand it correctly you can have btTriangleIndexVertexArray's that all reference the same data, albeit at a different scale?

3. How useful is it it to share meshes between the graphics-side and the collision-side? The physics only need vertex-positions and not texture-coords ect. so you could pack the data for the physics tighter. Could it actually be beneficial to separate collision and graphics data (provided you have enough memory)? Or is it (in theory) always better to try to share the two?

4. Also, how much sense does it make to use btBvhTriangleMeshShape for, say the entire level of FPS or similar game? I mean, do people actually do this, or do they rather approximate the the geometry with various static primitive shapes?

Would be very interesting to hear some of your thoughts on this!

[B_old]

The answer to 2. is yes.

[sparkprime]

1. you can have one big mesh, this can work ok. you can also have lots of collision objects or lots of parts. just do what is easiest given the data you have and then improve it from there if necessary.

2. you can create rigid bodies / collision objects that reference the same collision shapes with different scales, i think. never used this functionality though

3. see discussion here http://www.bulletphysics.org/Bullet/php ... f=9&t=4739

4. it is likely to work fine. you may need to do that + use some primitives/hulls in addition, to stop tunneling. depends on how fast your dynamic rigid bodies are when they are colliding with the level, and how they are constructed from primitives.

[B_old]

Thanks for your comments sparkprime!

I'm still not sure, whether it is better to have one big mesh for the mesh-shape, or several small ones. Does anybody know if bullet does any optimizations in the former case?

Maybe I was a little unclear, with what I meant by sharing mesh-data between the rendering side and the physics-side. I meant literally sharing. So that bullet addresses the same memory that D3D might keep in system memory. It seems like a bit of work and I wonder whether it gives a big benefit. Somehow it feels like it could be faster to grant bullet it's own copy, even though it might come from the exact same source.
The thread you are referring to doesn't touch this subject as far as I could see. However, the hint, that you can cull a few duplicate vertices, once you don't have to respect texture coordinates ect. is nice.

[sparkprime]

These days graphics meshes go in the graphics RAM

Also for performance, Bullet has to build additional datastructures to allow efficient spatial queries into the triangle mesh, so I actually doubt you would save much memory anyway.

Bullet optimisations both the object-level broadphase and the triangle-level midphase so as long as you pick your broadphase algorithm sensibly i doubt you'll notice a huge difference between having lots of objects and 1 single object.

[B_old]

These days graphics meshes go in the graphics RAM

Also for performance, Bullet has to build additional datastructures to allow efficient spatial queries into the triangle mesh, so I actually doubt you would save much memory anyway.

AFAIK D310+ keeps a copy of the graphics-data in system memory as well. Same as with managed stuff in D3D9. So I guess, on that account you could save the amount of memory that those meshes take up.
Maybe it makes more sense on an architecture where graphics and system memory are shared.

So, anybody who represented an entire level with a triangle mesh?

[sparkprime]

Ah yes if you have managed resources then you'll have it there but I don't know if you have access to that memory. Also if you are doing some sort of CPU vertex transformations or partial updates then you might have a shadow buffer sitting around. However I still don't think it's worth letting these details affect how you design your physics world.

[Sorlaize]

for 4. I think I remember Erwin saying depending on your scene (static/dynamic, paged and other factors) it might be better to block out your level mesh in simple primitive shapes for the physics. Do you need fully mirrored graphics-physics representations in a destructible scene? Even if you're generating arbitrary mesh debris you should be able to generate hulls at least.

But yeah I think the btBvhTriangleMeshShape is designed for that.

[B_old]

Sorlaize: That sounds reasonable, but I haven't looked into generating hulls yet.

I do however have another question regarding triangle meshes. Can I expect them to be exactly like the mesh I use for rendering, if I indeed use the same?
I have a situation where I use the same source-data for to create a mesh for rendering and a mesh for bullet. When I look at the mesh with bullets debug-renderer, it is not the same though! Entire triangles are missing, and there are connections between vertices that shouldn't be there. I double-checked all initializing parameters but couldn't find a problem so far. Can there be another reason for such behavior?

[sparkprime]

Sounds like you fucked it up, I have no problems like that. Check it with some small example.

[B_old]

I was using sizeof(IndexType) instead of 3 * sizeof(IndexType) for the triangleIndexStride. It seems to be working just fine now.

[sparkprime]

Heh I did exactly that the other day, but in some graphics code