Is there a standard way to store 3D meshes to easily communicate between libraries?

Question

In a 3D game lots of different systems need to know about geometry data, however the only way they seem to be able to agree to on in representing it by an array of triangles.

Can anyone recommend a good geometry manipulation library that will allow me to easily integrate the drawing library(OpenGL), the physics engine(Bullet), Serialization(Several 3D file formats) and my own code(objective-c++). Focus on the a representation between the drawing library and the physics engine. Also if the library can triangulate a mesh definition that would be very helpful. My code can work around what exists already.

Answer 1

There isn't really a standard format -- and there really shouldn't be, because you're asking about several widely different domains and applications of geometry data and efficient representations will differ for each.

That said, there are formats designed to facilitate content interchange. The most popular are Collada and FBX. This doesn't completely address your concerns though -- both formats are quite verbose and not actually well-suited to being used directly in memory, as a result. You'd probably want to condition them into some custom format your game can load most efficiently (the "array of triangles" you mentioned).

You generally want physics and render data to be different -- perhaps sourced from the same place, but there's no reason your physics meshes need to have colors and texture coordinates, for example. It's wasteful.

Answer 2

For a library I suggest you have a look at Assimp. It's a library for working with various mesh formats so you can just dump it in and get a full mesh importer with little in the way of work. It also allows you to load in a standardized format and output a custom one.

The problem is what format you store your meshes in will vary depending on your program and what features you need, what formats you are using internally. You are normally going to need some post-processing for things like converting filenames of images referenced by meshes. How are you going to link custom shaders and so on.

There are some standardized formats that you can use but they will tend to be over engineered for most realtime rendering and are more for use in the content creation pipeline. COLLADA is the main example (as the other post mentioned), it's found use from Sony with the PS3. Bullet Physics (and the Physics Abstraction Layer) apparently includes support for Collada. On the down side COLLADA is XML, so it requires parsing and needs to support a huge list of features making even a basic implementation quite a bit of work (for example it supports multiple coordinate systems, so if you want to support custom content you will have to take that into account, plain image textures have multiple levels of linages since the same format needs to support more advanced things like multiple textures and so on). With that said, in the past games often add support for importing the native formats of a 3d modelling program such as 3ds which wouldn't be too different so the overhead isn't that great. Although might be to much for mobile phones and some game console systems.

idGames such as the Doom 3 mesh format (MD5) is simply a plain text ASCII file. There are multiple files, one for geometry and another for animation. You could also have a separate one for physics as that will generally use lower polygon geometry.

Personally I would recommend using a binary format as your final mesh format. You can make a format that can be loaded into memory as basically a single block of memory and just requires some updating of pointers. The only potential problem is big endian vs little endian but just standardize on one and convert on the other.

Rather than using triangles it might be better to use an indexed vertex array of triangle strips for storage as it should save a bit of storage space (and ram when loaded into memory) but it does require some conversion to the format.