Sign in to follow this  

3d file format question

This topic is 4658 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Currently in my 3D engine I can load two types of file formats: quake 2 (.md2) and my own custom format from a .txt file. I am interested in why commercial file formats are so much more complicated than my own. Basically I simply have a header that contains info such as the number of objects, their offsets, names, etc. Then I have the object data itself basically each mesh consists of vertices, colours, texture UVs, bone weights and all sorts.Each of those are just stored sequentially. In my ImportMesh function it simply reads the header and then begins reading the appropriate mesh data into separate arrays: Vertices, Colours, TextureUV, etc that can be passed to the rendering API (OpenGL). Now that isn't difficult really and it works quite well but I see that many other file formats use many other structures such as Indices (or whatever) and their format is different and actually require more complicated code to properly import. I am wondering - is there a good reason for this? Many thanks David

Share this post


Link to post
Share on other sites
It's really about what you need. 3ds files, also got data for lights, camera and who knows what other stuff. If you need all that, 3ds is propably good. But if you dont need it, I think you better stick with your own file. Because that has exactly what you want it to have ;)

From a txt file? Do you mean you read ascii?
Personaly I use a slightly changed md3 loader.

np,Goodluck
xIshtarx

Share this post


Link to post
Share on other sites
as Ishtar said, it is really all about what you need and what you are using the model for.

For instance, indices are a list of indexes into the vertex array. The reason you would want this is so that you actually have less data than if you just list all the verteces (in complex models). Also, a lot of the time you will want to be passing these indeces to the video card as well as the vertex data, so you are actually saving yourself a step, instead of adding a step as you first thought.

Basically, create a format that fits your needs. It will probably change over time as you slowly make your engine more complex, but there is no point making your format more complex than you need it to be.

-Greg

Share this post


Link to post
Share on other sites
I read binary but I did use ascii when my engine first began (to get things going), now I'm just lazy to think of a file extension other than .txt will come up with one soon though.

I am interested in how often indices are used. I just use vertices but I have seen tutorials where a triangle struct is used to hold three indices to point to an array of verticess where the points are. I think its unnessesary but if I remember correctly there are some commercial file formats that do this also (md2 ?)

Whatis the advantage to making it more elaborate in general (not just using indices)?

Share this post


Link to post
Share on other sites
OK, I've been reading a bit.

Is it generally better to use ascii (words and numbers) rather than binary because this avoids making the file compiler and OS dependant. For example an Int might have differnt padding on another compiler or it might be written in reverse order on another OS (I think this is big or little endian?!)

So use a script-like file format. I had alook at the doom3 file format and it seems to be done this way.

Is this right/a good idea?

Share this post


Link to post
Share on other sites
Quote:
Original post by dmatter
Is this right/a good idea?


Yes and no :D

Text files are easier to work with because you can actually SEE the data and hand edit it, and then you can be sure exactly what the loader should get out of it. However they are bigger in size and much slower to load. Binary files on the other hand are smaller size, faster to load but harder to bugfix with (is the file wrong or the loader? its hard to tell when you can easily look at the data). Personally I would start with a text file and see how you go. Once your format is complete, and if the loading time is bugging you then write a binary loader (but don't delete your text loader - no reason you can't use both based on the file type). No point writing a binary loader if the text version isn't slow :P

Re: endianess. Yes binary files will screw this up, but its really not that hard to work around. Infact its probably easier to just write a little tool to change the endieness of your binary mesh files. But either way porting to mac will be hard even with text files so its not a huge issue IMHO.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
In any reasonably constructed model each vertex will be shared by multiple triangles.. hence the usage of indexes.

Assuming 24 bytes per vertex (position, color, and one set of texture coordinates)

A triangle list using raw vertices consumes 72 bytes per traingle.

A simple icosahedron model has 20 triangles, or 1440 bytes as a raw triangle list.

But in an icosahedron, each vertex is shared by 5 triangles. There are actualy only 12 unique vertices. 12 vertices consumes 288 bytes. Indexing those vertices with 20 indexed triangles uses 60 indexes for the model.

At 4 bytes per index (usualy you would use 2 byte indexes) the indexed triangle list uses 240 bytes. 288 bytes + 240 bytes = 528 bytes, well below half the space of a raw triangle list. The savings goes up even higher if you use triangle strips but goes down if fewer triangles share each vertex.

Also, considering the runtime complexity of finding duplicate vertices in a model, its clearly best that the model format itself is already stored efficiently rather than try to do it at load time.

Rockoon (Joseph Koss)

Share this post


Link to post
Share on other sites
lets see if i understand...

I can store indexes in the file, but when it needs to be rendered I would still have to send it all a vertices anyway i.e without indexes - Or is there a way to send indexes to Opengl/DirectX. Indexes just save memory and the memory saved increases as number of shared vertices increases.

The file format, when in binary: Faster, easier to load, portability issues. When ascii: Slower, (can be) harder to load/interpret, reduced portability issues (apart from file handling itself).

An ascii format can be more useful when considering extensibility because it is more script-like.

Is fstream portable - I would have thought it is.

Is there anything else that could be useful or interesting - I particularly liked Anon Poster's indexes talk.

Many thanks so far!

Share this post


Link to post
Share on other sites
I personally use the md2 format. I don't feel like making my own format, most modeling programs have an import/export for it, and it has everything I need and nothing more. I need keyframes(though skeletal animation would work as well), vertices, texCoords, and normals, that's it. That is exactly what md2 comes with. It is fast enough for me too. For me, it was also the easiest format to work with loading wise and drawing wise anyway.

Share this post


Link to post
Share on other sites
I started making my own format and because of this had to then create a conversion program that took an existing format (3DSMAX ASC scene) and create my own ASCII text format.

The format was very simple and had exactly what I needed.

However... this meant I had yet another format that was not supported anywhere.

I ended up just supporting DX static meshes and MD2 format. One for static (vertices stored on card) and the other or animated meshes.

I really went to town so to speak on the MD2 format as I had a lot of loading options which could basically re-arrange the data totally.

Have an option to calculate normals during loading which gave me lit models.

Also had an option to keep the indexing or to turn everything into a trinagle list (which is better for lighting).

I also improved the performance of the rendering routine by about 500% as a lot of stuff was recalculated when it was constant.

Also...as the texture coordinates are connstant for all frames.. I wrote the texture coordinates only once to the resultant array that cut down on the bandwidth by about 30%.

Share this post


Link to post
Share on other sites

This topic is 4658 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this