collision shape binary format

[sparkprime]

Is there a binary file format for storing bullet collision shapes efficiently? Load speed is very important. If not I'll make one and release it.

[sparkprime]

I'm also considering an offline tool to convert the binary form to/from XML or similar structured textual form.

[Sly]

There is a binary format for storing a generated BVH, but it does not store the shapes.

[sparkprime]

Hmm, is that because the generation algorithm is computationally intensive?

I've recently decided that since COLLADA is a general purpose format, there's no point me creating an additional one. I'm wondering now if I should create a specialist format for my own game or just to use COLLADA. I have no need to store graphics / FX, just rigid body shapes (probably just boxes, spheres, and concave triangle meshes for both dynamic and static objects).

[Sly]

Generating the BVH can take some time. I have a 320,000 triangle height map mesh that takes approximately five seconds to generate the BVH. PhysX can "cook" the same mesh in about two seconds, and not require the vertex and index buffers to be reloaded into the shape like Bullet. This is possibly something that Bullet could be extended to do in future.

[sparkprime]

What about gimpact?

[AlexSilverman]

Bullet allows you to serialize the BVH data to disk (the equivalent of PhysX cooking). An example can be seen in the ConcaveDemo (ConcavePhysicsDemo.cpp ~line 185).

Enjoy

- Alex

[sparkprime]

OK it sounds like my static concave needs are satisfied, but I'm still not sure how to proceed with my dynamic concave needs.

Well, I know there are two options - gimpact and convex splitting.

I tried to read the code for the convex splitting but didn't get far.

Does anyone have an objective comparison of gimpact and convex splitting?

Anyones experience in this area would be interesting.

[Sly]

Bullet allows you to serialize the BVH data to disk (the equivalent of PhysX cooking). An example can be seen in the ConcaveDemo (ConcavePhysicsDemo.cpp ~line 185).

Enjoy

- Alex

If I read the sample code correctly though, we still need to add the vertex and index buffers to the triangle mesh shape before loading the saved BVH data. Or am I completely wrong? PhysX cooked mesh data includes all data required for the mesh shape.

[AlexSilverman]

Ok, so maybe it's not exactly like PhysX cooking

It does however, seem to be enough to avoid the costly portion of the mesh creation process (bvh generation). Is that all you were trying to avoid, or did you want to just load one file and have that be it? If the latter is your case, maybe you could create a new format that combines the serialized bvh data and the index/vertex data? It might be too much work for the gains you'd get, but it would be interesting at the very least.

- Alex

[Sly]

A lot of work, yes. Besides, to share vertex and index buffers we still need to tell Bullet where those buffers are, so "cooking" would not be able to include those buffers. It's a nice thought, but the costs may outweigh the benefits.

[sparkprime]

I will need a file format to store collision meshes in, and if it's possible to store precalculated data in this format then that's definitely something I'd consider. I was thinking of one file for 1 rigid body - a compound shape, comprised of a concave mesh and a set of spheres/boxes. There will probably be mass, friction, etc in the file too, so it makes sense to use mass==0 as a "static" flag that determines how the concave mesh will be represented.

The concave mesh may have to be split (offline) into convex parts for dynamic meshes anyway, so doing more offline work to further improve loading time for static meshes (the bvh stuff) should not be a major undertaking.

Unless there is a problem internal to bullet that makes this hard.

Alternatively I could split up the static meshes with the same code that splits up dynamic meshes and forget about bvh altogether. Any thoughts?

[AlexSilverman]

I did something very similar to this (except I didn't include the bvh data) so that I just load one file which represents a shape, be it a mesh, compound, or primitive. It works great regardless, and wasn't too much work to get going.

- Alex

[sparkprime]

Maybe I should just implement the basic triangle data and wait to see if the loading speed is bad enough to justify the BVH precomputation.