Jump to content

  • Log In with Google      Sign In   
  • Create Account


Storing mesh data


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 gemini_   Members   -  Reputation: 237

Like
0Likes
Like

Posted 22 June 2012 - 05:48 AM

Right now I'm working on an FBX importer for my rendering engine. Everything is going pretty well but I was wondering what the best practices are for storing meshes in general . The way FBX works is that one file can contain multiple mesh parts that make up the whole "model", my instincts tell me to store it as a hierarchy in a graph structure, which is how they're originally stored in the file. Is this the pretty much the way to go, are there any alternatives?

Sponsor:

#2 DevLiquidKnight   Members   -  Reputation: 834

Like
0Likes
Like

Posted 24 June 2012 - 07:55 PM

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

#3 turch   Members   -  Reputation: 590

Like
1Likes
Like

Posted 25 June 2012 - 06:19 AM

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.

#4 bglanzer   Members   -  Reputation: 454

Like
0Likes
Like

Posted 25 June 2012 - 06:31 AM

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

Brendon Glanzer


#5 wolfscaptain   Members   -  Reputation: 200

Like
0Likes
Like

Posted 27 June 2012 - 02:34 AM

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.

#6 L. Spiro   Crossbones+   -  Reputation: 12231

Like
1Likes
Like

Posted 27 June 2012 - 02:56 AM

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
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

#7 phantom   Moderators   -  Reputation: 6790

Like
-1Likes
Like

Posted 27 June 2012 - 04:53 AM

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.

#8 gemini_   Members   -  Reputation: 237

Like
0Likes
Like

Posted 27 June 2012 - 05:13 AM

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?




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS