Which 3D Model format should I be using? [closed]

Question

Im writing a game engine and I'm wondering what 3D model format should I use/load/export? Obj seems universal and easy but it also appears to be unreliable in that most models out there contain errors and it doesn't store anywhere near as much as other formats.

There appear to be formats specifically for games such as MD2/3/5 but Im not sure, I use wings3d if I model, and I don't know what other details beyond purely loading what I need and support from the format Id have to implement, such as would I need to implement IK? and can I use scripted per piece animation rather than Inverse kinematics and bone rigging?

Leaky

Answer 1

Collada is an open XML based format for 3d models owned by the Khronos group(OpenGL standards body)

From the Collada.org FAQ:

The COLLADA 1.4.x feature set includes:

• Mesh geometry
• Transform hierarchy (rotation, translation, shear, scale, matrix)
• Effects
• Shaders (Cg, GLSL, GLES)
• Materials
• Textures
• Lights
• Cameras
• Skinning
• Animation
• Physics (rigid bodies, constraints, rag dolls, collision, volumes)
• Instantiation
• Techniques
• Multirepresentations
• Assets
• User data

Andromeda

I wouldn't use this format for real-time graphics. Collada is intended as an intermediate format for graphics production pipelines. Use it to convert to a more compact binary format, or it you will be waiting all day for it to load. – Umbria

Also consider that not all tools support the entire COLLADA feature set. – Measles

In the end I went with the ASSIMP library for geometry loading so anyone can use what they like so long as they support the necessary attributes – Leaky

Parsing Collada is as good as your parser works. Still I agree that it's more of a pipeline-format and contains way too much information, which a game engine probably won't need. Since Collada is text, it's compression ratio is great. Another thing of importance is the already mentioned fact that it's developed and maintained by Khronos. This leads to a really smooth transition between a Collad file and OpenGL because of the way information is stored (using VBOs combined with interleaved arrays leads to a big performance boost). btw ASSIMP supports only 1.4 and loading 1.5 leads to exceptions. – Dumps

@TomJNowell How did you find yourself with assimp? – Unpriced

One good example for collada being often too generic for real applications is, that e.g. Vulkan does not support quads but collada can contain quad based assets without a problem. So, to get past that you need to foresee what could possibly be contained in a collada document and then convert it to formats the application can handle. That might be a lot of work... and maybe speculative, too. – Petulancy

Answer 2

Before worrying about what 3D formats you want to support, I think you should really focus on what features you are planning to implement in your engine. Write those down as requirements, and pick the format that supports the most features from the list... as you'll want to showcase your engine (I am assuming you are planning for your engine to be publicly available). You might even want to roll your own format, if your engine has specific features (which is always a good thing to have for a game engine).

After that, support as many of the popular formats as you can (.X, .3DS, .OBJ, .B3D)... the more accessible your engine is, the more people will want to work with it!

Collada is a nice and generic format, but like Nils mentions, it is not an ideal format for final deployment.

Music

Answer 3

I use my own binary format. I've tried to use existing formats but always run into limitations. Some could be worked around, others where showstoppers.

Collada may be worth a look. I don't think that it's that good as a format to be read by a 3D engine. It's fine as a general data-exchange format though.

http://www.collada.org/mediawiki/index.php/Main_Page

Nationality

Answer 4

+1 for Collada. You may also want a custom native binary format for really fast loading (usually just a binary dump of vertex/index buffer data, plus material and skeleton data, and collision data if appropriate).

One trend in the games industry is to support loading a format like collada in the developer build of the engine, but also have a toolchain that exports an optimized version for release. The developer version can update the mesh dynamically, so as artists save changes, the file is automatically reloaded allowing them an (almost) instant WYSIWYG view of their model, but still providing a fully optimised release format.

Trusty

About native binary format, it's worth noting there already is a standard Binary XML format: en.wikipedia.org/wiki/Binary_XML – Kezer

@Kezer Well, not really. None that is industry standard anyways – Claimant

Answer 5

support Collada well, and then supply good converters to/from the other formats (this might be the hard part). This will give you maximum flexibility. Take a look at C4 engine

Leffler

Answer 6

Collada is great, but it lives more on the 3D app side of things. ie it's best used for transferring 3D data between applications, not loading 3D data from within a games engine. Have you looked into Lua? It's widely used in games because its a scripting language that's both ridiculously quick (perfect for games) and very flexible (can be used to represent whatever data you need for your engine).

Coenocyte

Of course :) but Lua can represent matrices, so building a 3D model format / parser is something that can be done – Coenocyte

Voted down - some people answer with "Lua" to any question they find. – Petulancy

@Petulancy It's technically not wrong. You can just generate a script that already contains the data you need to skip the parsing step; Same idea as with generating C code for assets. Not sure if it's a good idea, but it's not implausible. – Rhett