Jump to content

  • Log In with Google      Sign In   
  • Create Account


COLLADA vs AUTODESK fbx


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
20 replies to this topic

#1 butthead_82   Members   -  Reputation: 122

Like
0Likes
Like

Posted 09 October 2007 - 07:35 AM

Hi everyone I am trying to find out which one of these formats above has more promising future, which one has better support, which one would be better to use. As I understand both of these formats are supposed to be used to convert one format to another, though I read somewhere that .fbx can also be used in a game engine, is that wise? (I'm little suspicious) I heared people complain about .fbx, using various modelling packages with autodesk plugins usualy ended up with their applicatin crashing. Can you tell me something about this? Thanks for help.

Sponsor:

#2 Josh Petrie   Moderators   -  Reputation: 2954

Like
0Likes
Like

Posted 09 October 2007 - 07:47 AM

Last I checked, FBX was a closed format which you access via the FBX SDK. That was enough to turn me off then; I didn't feel up to wrapping the SDK in C++/CLI to be able to use it with my tools, and I could use the .NET XPath APIs to wrangle Collada quite easily. XML -- text -- is also a little nicer as an interchange format because the data is more-or-less human-readable.

Because of the above, I never used FBX so I can't comment on it beyond that. Collada supports a lot, but has a definite feeling of overengineering sometimes and can be a little awkward to handle at times. For the most part, I'm pleased with it.

I wouldn't really recommend using any format designed for interchange directly in a game, as they tend to be overly verbose and ill-suited to optimized load paths.

Josh Petrie | Core Tools Engineer, 343i | Microsoft C++ MVP


#3 butthead_82   Members   -  Reputation: 122

Like
0Likes
Like

Posted 09 October 2007 - 08:39 AM

I don't quite understand what you mean by "wrapping SDK in C++/CLI", could you explain that to me, please?

#4 Ashaman73   Crossbones+   -  Reputation: 6697

Like
0Likes
Like

Posted 09 October 2007 - 07:07 PM

I don't know fbx either, but collada. Collada has been adopted by many 3d tools, developers etc., so I think that this format will be the de-facto standard in the future. Collada supports all you need, including phyisics, animation etc.

As jpetrie already said, I wouldn't read collada or whatever format directly into my engine. I designed my own model-format optimized to my engine requirements and wrote a collada-converter.

An other tipp: don't write your own exporter ! Use an existing exporter and just write a converter. An exporter is tool bound and that is really a bad idea (learned it the hard way ;-) ).

--
Ashaman



#5 butthead_82   Members   -  Reputation: 122

Like
0Likes
Like

Posted 10 October 2007 - 04:44 AM

Thanks for info guys, I appreciate it

can you tell me what usefull tools for working with collada are there?

#6 Josh Petrie   Moderators   -  Reputation: 2954

Like
0Likes
Like

Posted 10 October 2007 - 05:39 AM

Quote:

I don't quite understand what you mean by "wrapping SDK in C++/CLI", could you explain that to me, please?

I develop in C#. The FBX SDK only provides a C interface, iirc. Which means I would have to write a wrapper around it in C++/CLI so that I could call it from my managed code.

Quote:

can you tell me what usefull tools for working with collada are there?

VS can generate C# code for handling Collada file's from the schema, but I've found this ugly and prefer XPath. There's FCollada and the Collada DOM SDK for C++.

Tool-wise, nearly every modelling package can export to it (I use XSI) and there are external tools like the Collada Refinery to perform content processing.

Josh Petrie | Core Tools Engineer, 343i | Microsoft C++ MVP


#7 bronxbomber92   Members   -  Reputation: 275

Like
0Likes
Like

Posted 10 October 2007 - 08:55 AM

Hi,

I was wondering why you wouldn't use collada directly in your engine?

#8 zedz   Members   -  Reputation: 291

Like
0Likes
Like

Posted 10 October 2007 - 09:09 AM

theres nothing wrong with using collada (loading/parsing is fast enuf with most datasets)
the major issue is how much to support, collada does everything under the sun, whereas for your game youre most likely only wanting a small subset of that, ie its overkill. i suppose theres nothing wrong with a having a collada-lite loader

#9 butthead_82   Members   -  Reputation: 122

Like
0Likes
Like

Posted 10 October 2007 - 09:12 AM

Quote:
Original post by bronxbomber92
Hi,

I was wondering why you wouldn't use collada directly in your engine?


Takes too much space and handling it takes too much time, kills the performance.

#10 Josh Petrie   Moderators   -  Reputation: 2954

Like
0Likes
Like

Posted 10 October 2007 - 09:26 AM

Collada is designed to be an interchange format; this basically means it's designed to support a lot of data formats, data sets, et cetera in a generic fashion. Collada in particular elects to do this via XML.

While the Collada schema imposes some restrictions on element ordering, it still allows for extensive cross-referencing between data sets, which ultimately makes for less-than-optimal load performance -- especially when you factor in the conversions neccessary to bring the Collada data into the in-memory format you'll actually be using for rendering.

The performance impact isn't generally a huge issue for the small datasets of hobby games. For professional games, the sheer amount of assets that need to be loaded is generally large enough that load-time optimization can become a valid concern.

It is certainly possible to use Collada directly, it's just not the best choice.

Josh Petrie | Core Tools Engineer, 343i | Microsoft C++ MVP


#11 butthead_82   Members   -  Reputation: 122

Like
0Likes
Like

Posted 11 October 2007 - 05:35 AM

Are you guys familiar with microsoft .x format. As far as I know it is closed format. Is it possible to find some unofficial specs...
Is there SDK for this format and what do you think of .x?

#12 Josh Petrie   Moderators   -  Reputation: 2954

Like
0Likes
Like

Posted 11 October 2007 - 06:17 AM

It's not closed; the specification is in the SDK. It's quite useful and very extensible due to its template-based nature and the ability to declare new data templates, but suffers from using a custom grammar, which means writing a loader without the D3DX helper functions to leverage the existing parser functionality is tough - you have to write the parser yourself.

I used to use it extensively until Collada came along.

Josh Petrie | Core Tools Engineer, 343i | Microsoft C++ MVP


#13 Spoonbender   Members   -  Reputation: 1254

Like
0Likes
Like

Posted 11 October 2007 - 07:25 AM

Quote:
Original post by zedz
theres nothing wrong with using collada (loading/parsing is fast enuf with most datasets)


It is slow. very slow. We used it for a small 1-month game project last year. We had plenty of engine-related problems, so our game ended up much simpler than we'd liked, which also meant that the amount of resources we needed to import via Collada was pretty small. And yet, loading the game took ~5 minutes, of which the majority was spent parsing XML files. Granted, it can probably be done faster, but XML *is* a lot slower than more compact formats. You don't want to have to go through too many megabytes of XML data every time you load your application.

#14 RobTheBloke   Crossbones+   -  Reputation: 2295

Like
0Likes
Like

Posted 12 October 2007 - 03:01 AM

Basically you can use the FBX SDK downloadable from Autodesk, but it can be a bit of a pain (actually, it's the big bain of my job, really not a fan). It's the main file format for motionbuilder, so if you are doing a lot of mocap or motion editing work it's probably a better choice than collada. It handles *most* things, but there can be a few problems with complex anim rigs (bake any animation before exporting otherwise expressions, driven keys etc can cause issues).

It's a bit lacking in the area of material, textures etc, and getting the anim data out can be a pain (the maya API documentation for MFnTransform and MFnIkJoint is an invaluable resource for understanding how to evaluate the anim data).

The SDK is closed source, but to be honest i wouldn't worry about that too much.


As for collada, I have slightly mixed feelings about it. On one hand the idea in principle is really good, however the exporters vary quite a bit in terms of quality, and the type of data they spit out. The Maya exporter is very well built, on the other hand the xsi one manually invokes the dot xsi exporter, loads the file back up into the FTK, then writes out the collada file. As i recall, the max one is built on top of the IGame interfaces.

In theory, most data should be pumped into the common profile for the format - but in reality, most data gets dumped in the app specific profiles. This can cause some problems if you are taking data from multiple packages since you end up doing a lot of if(from_maya) {} else if(from_max) {} type hacking.

The other issue i have with collada is that it's got a few things wrong in the design of the format that cause problems if you start working with NURBS or other surface types. (I'm on the Khronos collada panel - but they don't seem to be too concerned with fixing these problems). I also hate xml, but that's just me.

Thirdly, there is also the dot XSI file format (an FTK is available from the softimage site). People also seem to forget this, but there are exporters available for the major packages, and it is in my opinion the best format of the lot (it's open source as well).

Anyhow, whichever of those you go for, only use the SDK within a small converter app that dumps out the data you need into your own format. You really don't want to be linking to any of those libs within your game.

If you are using Maya, you are probably better off just using the Maya API and writing your own exporter imho. The XSI SDK is pretty simple to use as well, but avoid doing any Max plug-in work like the plague - it's horrible.

#15 butthead_82   Members   -  Reputation: 122

Like
0Likes
Like

Posted 12 October 2007 - 04:28 AM

Quote:
Original post by jpetrie
It's not closed; the specification is in the SDK. It's quite useful and very extensible due to its template-based nature and the ability to declare new data templates, but suffers from using a custom grammar, which means writing a loader without the D3DX helper functions to leverage the existing parser functionality is tough - you have to write the parser yourself.

I used to use it extensively until Collada came along.


Is .x supposed to be used by engine or is it asset exchange?

#16 mattnewport   GDNet+   -  Reputation: 1029

Like
0Likes
Like

Posted 12 October 2007 - 09:45 AM

Quote:
Original post by RobTheBloke
I also hate xml, but that's just me.


It's not just you, trust me.

http://xmlsucks.org/

#17 ldeej   Members   -  Reputation: 308

Like
1Likes
Like

Posted 12 October 2007 - 11:56 AM

Note also that FBX has issues with instancing, the do not really support instancing which means more post-processing to detect these. I am not sure if collada does, but I would be surprised if it does not.

Collada is sometimes way too verbose (related to the overengineering comment before), and the biggest issue I found for both was that it was not trivial (or not well documented) to add your own data/nodes/types. A while back I was trying to create my own custom shader type for an export pipeline for a personal project, but I could not find a good/easy way to do this, maybe I did not look hard enough.

FBX documentation is ok, and the samples are helpful.

Using either format as your main in-game format is not a good idea, both formats are meant to be data exchange formats, and performance/data layout are not main concerns for the corresponding SDKS/APIs.

Another option that you might want to explore is Crosswalk 2.0 from the Softimage guys, is similar to FBX, but it uses a template based system that is more extensible, but I do not think there are enough good samples for it.

#18 RobTheBloke   Crossbones+   -  Reputation: 2295

Like
0Likes
Like

Posted 18 October 2007 - 11:05 PM

Quote:
Original post by ldeej
Another option that you might want to explore is Crosswalk 2.0 from the Softimage guys, is similar to FBX, but it uses a template based system that is more extensible, but I do not think there are enough good samples for it.


a.k.a. dot xsi


#19 butthead_82   Members   -  Reputation: 122

Like
0Likes
Like

Posted 19 October 2007 - 04:20 AM

Is it possible to define custom nodes in collada?

#20 Kwizatz   GDNet+   -  Reputation: 1182

Like
0Likes
Like

Posted 19 October 2007 - 04:39 AM

Quote:
Original post by butthead_82
Is it possible to define custom nodes in collada?


You can use the "extra" element to insert your custom made elements or application specific stuff, but IMO that would kind of beat the purpose of COLLADA, since the data stored there would be application bound.




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.



PARTNERS