Alternate model format for DX9?
Author
I'm wondering - what model format is typically used in DirectX 9 (besides the .x format)? From what I've been reading, the support for .x is pretty awful, and Microsoft is even dropping support for the format in DX11. The animator on a project I'm working on can't even get one of his animated models to export to .x, and even when he could on previous versions of the model, there were always issues with them. Yuck!
So, I'm guessing that most projects use something besides .x. What alternate formats are commonly used? This is a commercial project, so the format/library used to load them would have to be something non-restrictive for commercial products.
Any help would be greatly appreciated. Thanks!
I would suggest collada (search Google for its specification) or just rolling your own formats.
DirectX .x files are still fine, I think... after all it's just a file format. The builtin exporters for DirectX models in most modelling applications are awful, though. For 3DSMax I suggest getting the kwXPort plugin, for Maya the CVXporter is doing a good job.
Other formats might still be interesting, though. Especially if the exporters are maintained. I therefore recommend Collada or FBX. Both come with well-maintained exporters for various 3d modelling packages, and both support a basic SDK to read them into your engine. On the loading side the Collada SDK is close to unusable in my opinion, FBX seems better.
That said, there's a generic model loader library called the Open Asset Import Library for which I wrote several loaders. It reads 20+ file formats, including DirectX .x, Collada .dae, Milkshape .ms3d, Lightwave .obj, 3DSMax .3ds and a lot more... FBX support is in the works at the moment. This library might save you the hassle of writing your own loaders.
Other formats might still be interesting, though. Especially if the exporters are maintained. I therefore recommend Collada or FBX. Both come with well-maintained exporters for various 3d modelling packages, and both support a basic SDK to read them into your engine. On the loading side the Collada SDK is close to unusable in my opinion, FBX seems better.
That said, there's a generic model loader library called the Open Asset Import Library for which I wrote several loaders. It reads 20+ file formats, including DirectX .x, Collada .dae, Milkshape .ms3d, Lightwave .obj, 3DSMax .3ds and a lot more... FBX support is in the works at the moment. This library might save you the hassle of writing your own loaders.
I would consider inventing your own custom format that contains the data you need in the format you need it. You can make it little more than a binary dump of your vertex and index buffers and any other data fields will be little more that the fields of your model object.
If you do that then your models will be very fast and easy to load, and you won't have to include any complex and large API into your actual game code. I wouldn't feel happy to include large third party APIs directly into my game code.
You'll of course have to write a tool to convert your models and run it on all of them as part of your build, but at least then your converter can load lots of different kinds of file without bloating and slowing your engine and it doesn't matter if your tool gets "bloated" by including several different model APIs.
If you do that then your models will be very fast and easy to load, and you won't have to include any complex and large API into your actual game code. I wouldn't feel happy to include large third party APIs directly into my game code.
You'll of course have to write a tool to convert your models and run it on all of them as part of your build, but at least then your converter can load lots of different kinds of file without bloating and slowing your engine and it doesn't matter if your tool gets "bloated" by including several different model APIs.
Quote:Original post by jbb
I would consider inventing your own custom format that contains the data you need in the format you need it. You can make it little more than a binary dump of your vertex and index buffers and any other data fields will be little more that the fields of your model object.
If you do that then your models will be very fast and easy to load, and you won't have to include any complex and large API into your actual game code. I wouldn't feel happy to include large third party APIs directly into my game code.
You'll of course have to write a tool to convert your models and run it on all of them as part of your build, but at least then your converter can load lots of different kinds of file without bloating and slowing your engine and it doesn't matter if your tool gets "bloated" by including several different model APIs.
For a final game run, I would also recommend a custom binary format, that loads in a blink of an eye, and could be quickly streamed and stuff.
But that's only for a final game(or techdemo). Using Assimp for a converting tool is very attractive solution, as it support many formats, that get exported from 3D packages, and you don't have to implement and maintain your own exporters. Assimp is very sweet and provides nice uniform data structure back to the application. I don't know how fast it actually is, parsing different models, but I guess, loading a binary dump from hard disk straight to the memory buffers will be faster. Also, when I compile it in release mode without boost, it's 14 MB big static lib ? That kind of concerns me including it into my application.
Maybe i'm doing something completely wrong with the compilation process ? Sorry for biasing the topic to Assimp, but if Schrompf(or someone else) could answer would be nice.
Assimp is quite slow. The reasons for this are that most 3d file formats do not contain plain vertex data only, but alot of additional data, and mostly in a very non-straightforward manner. It takes time to parse textbased files, and it takes time to reorganise data and calculate derived data. The other reason for the relative slowliness is the post processing applied to the imported 3D scene. Things such as calculating tangent data for your vertices, triangulating polygons or creating index buffers also cost time.
Therefore I also suggest inventing your own file format for quick loading, just like everybody else here did. Assimp is not intended for loading assets on game startup. You can do this, but it will take time. A binary format specifically designed to hold the data you need in an engine-specific way will load much faster. Assimp is intended to be an importer library - read files once when your graphics artist delivered them and save them in your custom file format for quick every-day reading.
Concerning the size of the static library: I never actually looked for how large my Assimp build got. It's just a temporary file, after all... if you link statically. In my case the final executable got larger by only a few 100 kb, and that's what counts for me. I guess it's due to the usage of templates, but I never checked.
Therefore I also suggest inventing your own file format for quick loading, just like everybody else here did. Assimp is not intended for loading assets on game startup. You can do this, but it will take time. A binary format specifically designed to hold the data you need in an engine-specific way will load much faster. Assimp is intended to be an importer library - read files once when your graphics artist delivered them and save them in your custom file format for quick every-day reading.
Concerning the size of the static library: I never actually looked for how large my Assimp build got. It's just a temporary file, after all... if you link statically. In my case the final executable got larger by only a few 100 kb, and that's what counts for me. I guess it's due to the usage of templates, but I never checked.
Yeah, the lib is something like concatenation of the object files, and I guess it get's pretty fat(duplicate code ?) when templates are involved. But for a final linkage to the exe(or dll) most of it would be eliminated, so no big worries. :)
Author
I see. So basically what you guys are saying is that I should take something like AssImp, use that to load the files, convert them to my own format, and then use that new format to load into the game?
Is there a tutorial or something on that? Thinking of loading all of the animations and heirarchical data and skin information is going to make my head explode.
Is there a tutorial or something on that? Thinking of loading all of the animations and heirarchical data and skin information is going to make my head explode.
I'm also using assimp as temporarily collada loader. The only problem is that the documentation is poor and the assimp viewer source is bit too complex just to search for a one example call. Using assimp requires patience. Took me a while to get an overview how to e.g. load the materials using that ::Get()
[Edited by - nvtroll on March 22, 2010 12:02:36 PM]
[Edited by - nvtroll on March 22, 2010 12:02:36 PM]
Concerning getting started with Assimp: there's the official documentation which explains the basic usage at http://assimp.sourceforge.net/lib_html/usage.html and how to interpret the imported data at http://assimp.sourceforge.net/lib_html/data.html. There's also this little tutorial at http://wasaproject.net16.net/?p=175
In my defense: I, too, don't like the material system. I would have preferred a flat structure because of easier access and clean debuggability. But this one wasn't my decision and now my spare time is way too lacking to implement an easier path to access it.
In my defense: I, too, don't like the material system. I would have preferred a flat structure because of easier access and clean debuggability. But this one wasn't my decision and now my spare time is way too lacking to implement an easier path to access it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement