Jump to content

  • Log In with Google      Sign In   
  • Create Account

COLLADA vs FBX... Are They Worthwhile for Generic Model Formats?


Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.


  • You cannot reply to this topic
18 replies to this topic

#1   Members   

969
Like
0Likes
Like

Posted 30 August 2014 - 05:19 PM

I'd like to use a more standardized model format that's a commonly-exported format across many 3D software production packages (Blender, Maya, 3DS Max, etc), and it seems that there are two: COLLADA and FBX. The problem is, it seems that there are multiple versions for these formats out there, and the exporters for each modeling package that supports these formats will provide the data in slightly different ways. Some even with missing features. It appears that the modeling package being used, the version of that package, the version of the supported exporter provided, and the file version are all variables that need to be considered. This is from what I've gathered so far, anyway.

 

I understand that these formats are meant to be generic formats to hold all kinds of data that the engine can interpret, and use in an optimized way, but due to this, it seems like these formats change on a regular basis. I mean, it seems that there's really no standard exporter for COLLADA let alone a solid, multi-platform importer (it sounds like ASSIMP has done a good job, though). FBX seems to change every 6 months, which requires a new SDK with radically different APIs. ASSIMP seems really nice since it can grab models from a variety of different formats, and provides a common interface for working with the data once loaded. The problem with ASSIMP is that it doesn't handle FBX as well as I thought it would (since the specs change frequently, I'm guessing). From what I've seen, FBX is used quite a bit.

 

Has anyone had any experiences related to handling COLLADA or FBX? If I could, I'd prefer to work with just FBX.



#2   Moderators   

49393
Like
3Likes
Like

Posted 30 August 2014 - 07:35 PM

I wrote my own (simple) collada parser, which was pretty easy armed with C#'s great XML parsing abilities, the specification PDF and some test exports from my artist.

However, I don't support the full collada spec, just the parts we need.
Yeah, the great thing about specifications is that everyone seems to bend (or just ignore) them, so new types of content that we haven't used before often won't work. e.g. The first asset from a new art tool might require me to tweak the importer because it stores the data slightly differently, or we might have to experiment with that new exporter and find the right combination of settings (such as ticking 'triangulate polygons' if my importer only works with triangles), etc...

I prefer to use collada rather than having to write custom exporters for every art tool... But yeah, instead I'm making one importer with a bunch of different code-paths added via trial and error from every art tool :/
I could've just used Assimp, but writing my own KISS importer means I can always deliver the results that the artists expect -- e.g. All sorts of Softimage-specific data about regions/clusters/sectors (which they wanted to use to define level areas) is imported inside non-standard <XSI> nodes, which aren't handled by Assimp.

#3   Prime Members   

2493
Like
1Likes
Like

Posted 30 August 2014 - 07:43 PM

That about sums it up. Pretty much the same experience i had with COLLADA. I bounced around forums trying to figure out why this or that would cause a crash or produce a different result between maya and 3ds max. Waiting for exporters to be updated by someone else killed it for me.

I had kept an eye on FBX but with the versions and heavy weight details and extras, I didnt have it in me to get into it after COLLADA. Eventually I figured these problems would never completely go away, so I wrote my own, a sort of tag based binary COLLADA.

I figured the time being wasted fighting and understanding the output from these model packages and file formats would be better spent on something concrete, like an exporter for my own format.

In the end the time was well spent, I have an exporter, I have a file format, I can add sections to it to support future (game specific) ideas, I control how the data is ordered and read in, if it breaks it means the modeling package changed (rare), I can ignore what I dont need during the export (smaller files).

I will say though, If I hadnt gotten pretty deep into COLLADA in the first place, getting the animation data right probably would have been more confusing.



#4   Members   

3261
Like
3Likes
Like

Posted 30 August 2014 - 10:34 PM

These are just some of the reasons we created the Open Game Engine Exchange format (OpenGEX):

 

http://opengex.org/



#5   Members   

24827
Like
2Likes
Like

Posted 30 August 2014 - 11:57 PM

These are just some of the reasons we created the Open Game Engine Exchange format (OpenGEX):

I’ve been spending quite a while on game-data-formatting tools, especially FBX.  There are some gripes I have with it and have been in contact with Autodesk staff to possibly get some things patched/fixed.
 
Without knowing if my input to Autodesk will ever be utilized, this is an interesting project to me.  I certainly have some input to give when it comes to 3D model formats.
 
Is there a way I can join this project?
 
 
L. Spiro

#6   Members   

969
Like
1Likes
Like

Posted 31 August 2014 - 11:27 AM

I have seriously almost gone the COLLADA here and there since late 2012, but then I kept remembering how "well" I did with my .x parser, and how incompetent I was in grabbing data properly. That said, it's XML-based, and that's pretty easy to parse with an XML-parsing library, such tinyXML in C++. C# does have some good XML and JSON parsing abilities. I just wish we used XML more with our Unity projects at work lol. I've been hoping for some sort of person or group to push a new, tighter-spec'd format to replace COLLADA, and it looks like OpenGEX may be on the right track for that.

 

EDIT: Eric Lengyel, on 30 Aug 2014 - 9:34 PM, said:

snapback.png

These are just some of the reasons we created the Open Game Engine Exchange format (OpenGEX):

 

http://opengex.org/

When do you think you'll have an exporter ready for Blender? That's currently what I use since it's free, stable, highly-functional, and there are communities of artists out there with Blender models you can download for free. It'd be pretty easy to get a few models of Sintel with various animations to try different tests.


Edited by Vincent_M, 31 August 2014 - 11:34 AM.


#7   Members   

236
Like
1Likes
Like

Posted 31 August 2014 - 07:38 PM

I have Assimp and SDKMesh (for DXSDK sample media) importers, and plan on creating another importer utilising the FBX SDK shortly to support morph targets (Assimp doesn't do morph targets currently).

 

I like Assimp. It provides much more than just supporting a number of formats for getting data into your engine. It also has a wide range of asset "conditioners", i.e. calculating tangents/bitangents, joining/optimizing, removing redundant stuff, UV conversion of spherical, etc. mapping to standard UVs, ensuring mesh instancing is correct, generating smooth normals, splitting large meshes, triangulation, conversion to other coordinate systems, etc.

 

If I want to use or test an asset I haven't created, importing it via an Assimp is a good first step for getting it clean.



#8   Members   

661
Like
0Likes
Like

Posted 01 September 2014 - 01:34 PM

Anyone got a look at glTF yet?
https://www.khronos.org/gltf
http://www.gltf.gl

I unterstand it like they are advertising it as an optimized run-time-format which can be created out of a COLLADA file.
The format specification is not yet finished though.
(although LibreOffice already supports it)

Regards
Markus

Edit: this link gives a better explanation about what glTF is
https://github.com/KhronosGroup/glTF/blob/master/specification/README.md

chaos, panic and disorder - my work here is finished


#9   Members   

3261
Like
0Likes
Like

Posted 01 September 2014 - 10:31 PM

 

These are just some of the reasons we created the Open Game Engine Exchange format (OpenGEX):

I’ve been spending quite a while on game-data-formatting tools, especially FBX.  There are some gripes I have with it and have been in contact with Autodesk staff to possibly get some things patched/fixed.
 
Without knowing if my input to Autodesk will ever be utilized, this is an interesting project to me.  I certainly have some input to give when it comes to 3D model formats.
 
Is there a way I can join this project?
 
 
L. Spiro

 

 

An updated specification for OpenGEX probably won't be in active development until sometime in 2015. If you have suggestions and/or feature requests, please feel free to send them to me at lengyel@terathon.com.



#10   Members   

3261
Like
0Likes
Like

Posted 01 September 2014 - 10:33 PM

snapback.png

These are just some of the reasons we created the Open Game Engine Exchange format (OpenGEX):

 

http://opengex.org/

When do you think you'll have an exporter ready for Blender? That's currently what I use since it's free, stable, highly-functional, and there are communities of artists out there with Blender models you can download for free. It'd be pretty easy to get a few models of Sintel with various animations to try different tests.

 

The Blender exporter is currently in development and should be available pretty soon.



#11   Members   

969
Like
1Likes
Like

Posted 02 September 2014 - 10:57 AM

I'm excited to try it out. In the meantime, I setup the FBX SDK, and began exporting models from Blender (FBX 7.4). Surprisingly, the SDK with its constant API changes, still work. Btw, if I were to write a community-driven, open source, engine utilizing the FBX SDK, would I be able to distribute my engine? I understand that I wouldn't be able to distribute Autodesk's own SDK along with it, but if I were to distribute the built binaries on my end, would I have any issues there?

 

Btw Eric, I checked out your C4 Engine back in 2011, and it's impressive! It inspires me to become better at what I do.



#12   Moderators   

41253
Like
0Likes
Like

Posted 02 September 2014 - 01:25 PM

We've used collada for just about everything for about six years or so, circa 2008.

 

Very versatile, and very steady standard. Especially considering there is a straightforward ISO standard for the format you can know what to expect. Anything that doesn't conform to the standard is a bug. 

 

For final builds we transform the data into a format that loads directly into memory, but as an intermediate state the dae files are nice for everything. As they are XML you can even diff the files to some extent and easily manipulate them in code if necessary with common and standard libraries for various languages.


Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.


#13   Moderators   

49393
Like
1Likes
Like

Posted 02 September 2014 - 03:47 PM

Especially considering there is a straightforward ISO standard for the format you can know what to expect. Anything that doesn't conform to the standard is a bug. 

What do you do when you come across these bugs? Report them to Autodesk and then hold your breath for 5 years? :D :lol:

#14   Members   

906
Like
0Likes
Like

Posted 02 September 2014 - 05:20 PM

These are just some of the reasons we created the Open Game Engine Exchange format (OpenGEX):

 

http://opengex.org/

Interesting. Can you save the file as binary? That would be an important feature.



#15   Moderators   

49393
Like
3Likes
Like

Posted 02 September 2014 - 05:33 PM

These are just some of the reasons we created the Open Game Engine Exchange format (OpenGEX):
http://opengex.org/

Interesting. Can you save the file as binary? That would be an important feature.
For an interchange format it's not really that important -- games don't use Collada/FBX/ogex files directly, so they don't have to be optimized for loading. You should always convert from your interchange formats to a binary format that's optimal for your specific engine.

It might be interesting for OpenGEX to additionally define a game-ready binary format that's useful for 90% of devs though :)

When I started using Collada I was worried about simple 1MB models being stored as 60MB of text/xml... But it seems to work fine as all the decent repository systems compress text files before storage/sync anyway.

#16   Moderators   

41253
Like
0Likes
Like

Posted 02 September 2014 - 07:25 PM

Especially considering there is a straightforward ISO standard for the format you can know what to expect. Anything that doesn't conform to the standard is a bug.

What do you do when you come across these bugs? Report them to Autodesk and then hold your breath for 5 years? :D :lol:
Currently using OpenCollada plugins for import/export into Maya. If we can't fix it or don't want to, just report them to the community.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.


#17   Members   

3261
Like
0Likes
Like

Posted 02 September 2014 - 09:42 PM

We've used collada for just about everything for about six years or so, circa 2008.

 

Very versatile, and very steady standard. Especially considering there is a straightforward ISO standard for the format you can know what to expect. Anything that doesn't conform to the standard is a bug. 

 

Unfortunately, the reality is that most Collada exporters don't follow the standard, so you can't know what to expect a lot of the time. We had been using Collada exclusively since 2005, but the problems had become so bad that the C4 community decided that they needed something more reliable. (And no, FBX is not better.) I wouldn't have spent so much time developing OpenGEX if Collada worked. In general, Collada is unstable (e.g., the right way to do things changed drastically from one version to the next), over-engineered (e.g., too much abstraction with things like accessors), and under-documented (e.g., ask almost anyone what the proper way to interpolate Bezier keyframes in Collada is, and they won't be able to get it right even if they've read the latest spec from cover to cover). I personally find that the data in a Collada file also isn't organized very well, but other people may not have a problem with that.



#18   Members   

3261
Like
0Likes
Like

Posted 02 September 2014 - 09:48 PM

Btw Eric, I checked out your C4 Engine back in 2011, and it's impressive! It inspires me to become better at what I do.

 

Thanks! Version 4.0 is coming out soon, and it's a huge update, a bigger step forward than we've ever released before.



#19   Members   

906
Like
0Likes
Like

Posted 03 September 2014 - 09:07 AM

 

 

These are just some of the reasons we created the Open Game Engine Exchange format (OpenGEX):
http://opengex.org/

Interesting. Can you save the file as binary? That would be an important feature.
For an interchange format it's not really that important -- games don't use Collada/FBX/ogex files directly, so they don't have to be optimized for loading. You should always convert from your interchange formats to a binary format that's optimal for your specific engine.

It might be interesting for OpenGEX to additionally define a game-ready binary format that's useful for 90% of devs though smile.png

When I started using Collada I was worried about simple 1MB models being stored as 60MB of text/xml... But it seems to work fine as all the decent repository systems compress text files before storage/sync anyway.

 

It slows down the art pipeline. At critical parts of the project your going to be exporting huge scene into your world editor, maybe 100's of times a day.






Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.