Storing mesh data

Theirs lots of different ways to store meshes, just use what is best for what you intend to do.

Is there any reason to store an entire hierarchy? An FBX file needs to be able to represent an entire scene, but an individual mesh shouldn't need to be broken up into an arbitrary hierarchy. I store a mesh as a collection of submeshes, each of which is material data and a vertex buffer.

There are many different formats. Its best to look at different file formats and see how thier data is stored. If you look at milkshape (to me its one of the easier model formats to load from), if I remember right, first the vertex information for the entire model is stored. Then the index, or triangle data is stored for each mesh subset which includes normals. After which the material information is stored, and then finally bone and weight information.

The link below offers the order of the data and I believe there is a link that breaks down milkshape structures.
http://content.gpwiki.org/index.php/MS3D

3D model formats is one of the areas in programming where it is very common to remake code specific for every project.

FBX was intended to hold a whole lot of data which you probably don't need, and in a way that probably doesn't suit your application.
Therefore it is common to convert models from whatever format, to a format that can represent your internal structures as best as possible.

So, if your internal structure (as in, your actual code) holds an hierarchy, store them in the file the same way.

Is there any reason to store an entire hierarchy?

Yes.

An FBX file needs to be able to represent an entire scene, but an individual mesh shouldn't need to be broken up into an arbitrary hierarchy. I store a mesh as a collection of submeshes, each of which is material data and a vertex buffer.

Yes they do. This is how all 3D editors represent their data, and as such most auxiliary data such as animations etc. are expressed with such a hierarchy in mind.
I learned this the hard way when making my first 3D format. I could load all of my test samples fine, but when my engine started being used for commercial work I discovered that many artists tend to animate certain parts of models by adding meshes as children of bones.
I had no hierarchy and it was too complicated to modify my system to add support for this kind of animation, and instead I just had to tell the artists that this was a limitation of the engine, and they can’t animate this way.

There is no real difference between a “scene” and a “model”. Either a model is a very simple scene, or a scene is a very complex model. In the world of 3D graphics, it all needs to work the same, and no such distinction exists.


It is absolutely unacceptable not to have a hierarchy within your models. As far as this goes, follow your instinct; there are no alternatives.

As for the rest, there are nothing but alternatives. You obviously know that certain information such as vertices, normals, material, etc., are vital, so there is no point in mentioned that you need to include them. There are certain things you can do, however, to reduce the sizes of that data. I have posted a few ideas here.


One of the final decisions you would need to end up making is whether or not to embed resources such as animations and textures.
The best answer is to support both embedded and external. Embedded is very convenient while external is helpful in reducing data sizes whenever it is possible to share.
For convenience, I start with things embedded, but make a plan for an easy way to make them optionally external in the future.


L. Spiro

I disagree that embeding resources directly is a good idea - aside from the sharing issue it complicates loading as you have to load the data and then parcel different pieces off to different 'creation' functionality to get the correct source types back.

My favoured system is to split the data up into files, generally a 'header' and 'payload' split. The header containing the information for that mesh and the 'payload' being the data.

So for a model you might have a header file (.mh) which describes the size of the vertex buffer data, the size of the index buffer data and which material it requires. This data is then used to kick loads for that data which can be loaded directly into correctly sized chunks of memory in a GPU friendly format without dicking about having to parse extra files and the like.

Materials are handled in a simular manner where in a material has constant data and details as to which textures it requires, which again are in a 'game ready' format.

On a related note; your 'engine' should not be loading FBX files directly - this is an interchange format, before you engine sees it you should have processed it into a 'engine ready'/'gpu friendly' format so that you can directly load things as quickly as possible.

Loading a vertex buffer should be nothing more than;
1) load file
2) create vetex buffer via 3D API of choice with data supplied
3) delete staging data

If you are parsing things and trying to refine model formats etc then you are Doing It Wrong.

Going to go with the hierarchy then, it makes more sense when concatenating transforms and handling animation.

@L. Spiro: nice article, I'll definitely use it as a source when I get my feet on the ground with this.

@phantom: Yeah I figured doing all that processing at run time would be too slow, basically I'm creating a command line tool that parses models and spits out a binary representation that I can just load directly into memory and throw in a vertex buffer. I plan to include a header at the beginning of the file that specifies all the sizes of the different structures. As far as materials go is it just storing the shader constants and texture file names?