Jump to content
Sign in to follow this  
  • entries
  • comments
  • views

Progress on "IOF" file format for OBJs

Sign in to follow this  
Alex Hopkins


I have finished "spec 1" of my custom model format, IOF. It is intended to remove a lot of the complexity of OBJ files that I won't be using but also introduce important features that I feel OBJ files are missing.

I am splitting the work of this format up until smaller "specifications" so that I don't spend months on finishing the complete model format. The model file contains the spec version it was made for and so all files can be loaded for backwards compatibility. Unfortunately certain features will require a re-build of the IOF file from the original OBJ file.

For example, in "spec 2" I plan to support mesh groups and hierarchies. The former is partially encoded in the original OBJ file as separate group entries but the latter isn't supported at all. So a "spec 1" IOF file will have lost the group information, meaning it can't be upgraded to spec 2.

Currently, "spec 1" is very simple. Instead of the multiple separate index values for position,normal and texture coordinates in the OBJ file, the IOF file stores unique vertices and indexes to them as a whole. That means that more vertices generally will be output from the IOF than were stored in the OBJ but it also means that the Index into the vertices is compatible with OpenGL and DirectX indexed arrays.

To achieve this, an 8-tuple is used as the key in a Dictionary. This 8-tuple is merely the entire vertex information, comprising the position, normal and texture all together. This uniquely identifies each vertex. The 'faces' list is iterated through and every time, the dictionary of unique vertices is checked for that vertex. If the entry exists, the index is returned (the index is stored inside the vertex structure as Dictionary classes generally don't care about ordering) and stored in the Index list. If the entry doesn't exist, it simply creates a new vertex, fills out the index and adds it to the Dictionary before adding to the index list.

One of the features I wanted from the IOF model format was easy serialisation and deserialisation. Parsing through an OBJ file isn't hard, but its more cumbersome than it ought to be. Using a serialising system allows JSON objects to be used instead of plain-text line prefixes, making later deserialsing much easier.

The single down-side to this (that I can see) right now, is that the exported IOF files are in the order of 4 times the size of the original. This is a combination of the extra vertex information and also the names of the JSON fields being output for each vertex. This issue takes an ~90kb file up to ~250kb. While this isn't going to fill a hard-drive yet, I expect that IOF Spec 2 will have to support compression of some kind. A quick test shows that the 250kb IOF file is zip compressed down to ~23kb, a 90% saving in disk space. This must be optional though, as it will obviously put extra computation time on the deserialising later on.

Sign in to follow this  


Recommended Comments

There are no comments to display.

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

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!