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?

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.

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.

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.

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?

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.

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

Is it possible to define custom nodes in collada?

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.