Storing mesh data
Members - Reputation: 237
Posted 22 June 2012 - 05:48 AM
Members - Reputation: 586
Posted 25 June 2012 - 06:19 AM
GDNet+ - Reputation: 204
Posted 25 June 2012 - 06:31 AM
The link below offers the order of the data and I believe there is a link that breaks down milkshape structures.
Members - Reputation: 200
Posted 27 June 2012 - 02:34 AM
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.
Crossbones+ - Reputation: 7256
Posted 27 June 2012 - 02:56 AM
Is there any reason to store an entire hierarchy?
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.
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.
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.
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums
Moderators - Reputation: 5016
Posted 27 June 2012 - 04:53 AM
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.
Members - Reputation: 237
Posted 27 June 2012 - 05:13 AM
@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?