7 replies to this topic

[Xarles]

I am currently playing around with creating a game engine of my own. I have, until now, used .x models. It was quite simple with the built in functionality DirectX provides. But recently I have been moving towards OpenGL. I have also started noticing that .x popularity and support is down. So I am looking for a new model format. Even with libs such as 3dslib, 3ds loading is a pain. I tried Collada, that was a nightmare. (I realize now that it was not meant to be used directly anyway, oh well) But I have seen some advocate a custom format.

I am (at first) just planning on creating a really basic testing game, composed primarily of cubes. As such, I don't think that I will need anything more complex than a .obj. My problem will arise when I need something more complex, such as animation.

So: What is best? Using an established format, or rolling out my own? (First by using plain .obj but then slowing adding my own functionality to it)

(Sorry for the long post without much of a question, I guess what I really want is just some reassurance from the community and to see if there is a general consensus on what is the best course of action)

[Tordin]

I use Assimp, it´s easy, it´s efficent and stable, and they guys behind it are just great!
Assimp imports tons of formats and make it all blend togehter into one good pice. (you need to extract the vertex & index data and such aswell)


if you dont like that you probably have to create your own format, it isent that hard, just time consuming!


Cheers!

[Chris_F]

You really shouldn't be using any of those formats with your game. OBJ, 3DS, COLLADA, etc are good formats for distributing models to artists and working on them, but they are no good for distributing with a game. They are textual formats, which means they store the information inefficiently. Even if you compress them, you still have to parse them when loading, which is a slow process. You shouldn't be processing any of your assets during run time. They should be processed once and then packaged with the game in a format that can simply by copied into memory and used directly.

[Ravyne]

Chris makes a good point -- those formats aren't preferable for "retail" builds.

If, for convenience, you want your in-production code to be able to load those file-types, that's reasonable, but don't ship your final game that way. You can use the Assimp library in your code during production, but before you ship you should switch your game to a custom format, and create tools to convert your assets to that format. You can essentially just copy & paste the code from your in-production game (using Assimp) into a new code base to create this tool -- you just need to write the data out to a binary file instead of creating buffers and such with it.

This will keep load-times for your customers to a minimum, and also make better use of bandwidth if you are distributing digitally (or trying to fit onto a disc for that matter).

That said, you want to get your pipeline in place sooner than later so that you've got a chance to test it -- you don't want to just be converting all your assets for the first time a month before you release.

[Samurai Jack]

Struggle no more, just take a look at Open Asset Import Library.

http://assimp.sourceforge.net/

Common interchange formats

•Collada ( .dae )
•Blender 3D ( .blend )
•3ds Max 3DS ( .3ds )
•3ds Max ASE ( .ase )
•Wavefront Object ( .obj )
•Stanford Polygon Library ( .ply )
•AutoCAD DXF ( .dxf )
•LightWave ( .lwo )
•Modo ( .lxo )
•Stereolithography ( .stl )
•AC3D ( .ac )
•Milkshape 3D ( .ms3d )
•* TrueSpace ( .cob,.scn )

Game file formats
•* Valve Model ( .smd,.vta )
•Quake I Mesh ( .mdl )
•Quake II Mesh ( .md2 )
•Quake III Mesh ( .md3 )
•Quake III BSP ( .pk3 )
•* Return to Castle Wolfenstein ( .mdc )
•Doom 3 ( .md5* )

Motion Capture
•Biovision BVH ( .bvh )
•* CharacterStudio Motion ( .csm )

Other file formats
•DirectX X ( .x )
•BlitzBasic 3D ( .b3d )
•Quick3D ( .q3d,.q3s )
•Ogre XML ( .mesh.xml )
•Irrlicht Mesh ( .irrmesh )
•* Irrlicht Scene ( .irr )
•Neutral File Format ( .nff )
•Sense8 WorldToolKit ( .nff )
•Object File Format ( .off )
•PovRAY Raw ( .raw )
•Terragen Terrain ( .ter )
•3D GameStudio ( .mdl )
•3D GameStudio Terrain ( .hmp )
•Izware Nendo ( .ndo )

[Xarles]

You really shouldn't be using any of those formats with your game. OBJ, 3DS, COLLADA, etc are good formats for distributing models to artists and working on them, but they are no good for distributing with a game. They are textual formats, which means they store the information inefficiently. Even if you compress them, you still have to parse them when loading, which is a slow process.

Isn't 3DS a binary format?

Chris makes a good point -- those formats aren't preferable for "retail" builds.

That's what I figured. When I was first starting out years ago I remember wondering why I couldn't find .x or .3ds or any other model files in the Program Files folder for games. I thought it was because they put them into resource data files. But I guess they do both.

You shouldn't be processing any of your assets during run time. They should be processed once and then packaged with the game in a format that can simply by copied into memory and used directly.

If, for convenience, you want your in-production code to be able to load those file-types, that's reasonable, but don't ship your final game that way. You can use the Assimp library in your code during production, but before you ship you should switch your game to a custom format, and create tools to convert your assets to that format. You can essentially just copy & paste the code from your in-production game (using Assimp) into a new code base to create this tool -- you just need to write the data out to a binary file instead of creating buffers and such with it.

So custom format it is then. By binary you mean use iostream ios::binary then create a struct/class and just dump/read it all at once, right?

This will keep load-times for your customers to a minimum, and also make better use of bandwidth if you are distributing digitally (or trying to fit onto a disc for that matter).

That's always a good thing!

That said, you want to get your pipeline in place sooner than later so that you've got a chance to test it -- you don't want to just be converting all your assets for the first time a month before you release.

Exactly, that's why I'm asking now.

[Ravyne]

So custom format it is then. By binary you mean use iostream ios::binary then create a struct/class and just dump/read it all at once, right?

More or less, but the particular API isn't the issue, or even (necessarily) that you can do a straight read into a struct/class, although that's often a benefit. By binary I basically meant "non-textbased" -- you don't want to be parsing some complex file format at load time, but simple transformations are reasonable (certain data doesn't have to be in the file, but you might want to reconstruct it from data that is) and compression is common, particularly on the consoles (loading less data and decompressing it is often quicker than loading more uncompressed data given the disparity between CPU speeds and Disc I/O).

[Xarles]

I get it now. Thank you for your help.