Our Delta Engine supports Collada files for 3D Models since we have worked with Collada for many projects (since 2005). However the support for Collada .DAE files in 3DS Max 2011 or Maya just gets worse every year. No one is actively working on a plugin anymore. ColladaMax is dead, Feeling Software is not working on Collada anymore, OpenCollada (open source collada support) has done nothing for a year now, Sony does not like Collada anymore, Autodesk wants everyone to use FBX and never really supported collada well, etc.
So should we give up on Collada? Well, yes, the artists will no longer use Collada (we still support it for our engine and content importers) and instead export everything in FBX, which works fine out of the box in 3DS Max or Maya (or XSI or Blender, etc.). Now we got a bunch of FBX files (and some older collada files we still want to support) and we are way too lazy to write a new importer right now (we want to work on our 3D SoulCraft TechDemo now). There is the FbxConverter tool you can download from Autodesks website (for free, you just need to register). With this tool you can freely convert from FBX to Collada or one of many other formats (many different FBX formats, 3DS, OBJ, or DXF). The resulting collada .DAE file is MUCH better than one exported directly from 3DS Max or Maya (at least if the artist does not have the latest FBX exporter installed). It seems to be in a more standard format, it exports all animations, bones, skin, camera, spline, etc. information out where the standard Autodesk Collada exporter leaves this all out and makes the format useless. Sadly ColladaMax, OpenCollada, etc. all do not provide a plugin for 3DS Max 2011 or 2010 because no one is working on that, older versions like 3DS Max 2009 work fine, but we had our problems with those plugins as well. Note: Feeling Software still supports FCollada, but it is not longer a free plugin, you need to get a commercial license, but we had too many problems with FCollada in the past to go that route again (some stuff works great, other stuff not so much, at least for us).
I will report back how our implementation goes with all this format mess :)
References:
Update 2010-11-18: While Collada (including converted fbx files and yes, I tried many different converters and exporters) still works great for simple static meshes and animated meshes, it just causes too many problems with many of our more advanced content. While we might continue to support Collada in the future (I am not so sure right now), we will switch completely to importing FBX files directly now. This gives us much more flexibility, but it of course also adds lots more work to support FBX completly (e.g. there is no easy managed library to load FBX files, you gotta use the native FBX SDK). But everyone else uses FBX too (Unreal, Unity, most modeling tools, etc.), so I guess we have to jump on that bandwagon too. Another good thing is our artists already use FBX and they don't care how stuff is converted, it just should work. Another important aspect is that we want the ability to convert game content and levels back into FBX files (we used collada for that before), this way a nice interaction can happen between modeling tools like 3DS Max or Maya and the engine editors (but we are not there yet obviously) :)
For me the following put the nail into the coffin for getting away from the FBX to collada converted way. We had additional problems like missing material info and no tangent data that could be reconstructed from the original FBX file, but it turned out to be too much work and there are plenty of other subtle problems with the conversion (it looks fine at first, only after working with it a while you see more and more stuff not working the way you want):
From the FBXConverter Documentation by Autodesk:
What’s not supported by COLLADA
The following is a list of elements that DAE (COLLADA) do not support on
export or import.
■ Triangles, polylist, and polygons. The FBX Converter exports polygons
without holes, and imports them without holes and triangles.
■ Bake & single matrices
■ Variable sampling rates.
■ Absolute Paths (when invalid)
■ Instances
■ Skew
■ Non-standard Materials and maps for different parameters
■ Orthographic cameras
■ Normals (for skin and shape)
■ Light parameters
■ Vertex animation
■ Material parameters animations
■ Effects specialized profiles
■ COLLADA physics
NOTE Export or import to DAE (COLLADA) can destroy or produce unpredictable results for some elements.
We also tried putting some FBX files into the XNA Content pipeline to see what comes out at the other side, but there were way too many restrictions for us to work with the XNA Content pipeline. I am happy to see that XNA's FBX support is getting so much better (I used it last in 2006 and it totally sucked), but the following things were just too annoying:
■ All pathes must fit, including textures, shaders, and whatever else is in the fbx file. File formats also have to match, artists love to use .psd files, but that is nothing I want to support (there is a .png file with the same name right there, but the content processor does not see it). All of our FBX models we tested used absolute paths that were just not available on the content server (or my machine for testing). While FBX ASCII files can easily be edited, this is still a show stopper for us. While a small XNA team might be ok with this restriction (you can just use relative paths in 3DSMax when exporting and make sure all images, shaders, etc. are in place), I don't think this is the right way for us.
■ Many files caused other compiling issues, for example most of our animated meshes use not just a standard skeleton and bones, but some other system (e.g. CAT). Again, this can be sometimes fixed before exporting, but it just does not work automatically, it is always a custom process with lots of fiddling around. The following error was just too annoying to me to try this out any more (especially because you find not much useful information in the internet about problems like this): Skeleton not found. Meshes that contain a Weights vertex channel cannot be processed without access to the skeleton data.
■ Finally the process always takes way too long, we spend already most of the content server time inside the XNA content pipeline (to convert stuff to WP7), hopefully loading FBX directly instead of converting them to collada or going through the XNA content pipeline is way faster ;)
■ Even with all these problems the XNA Model Processor has some cool tricks up its sleeve. For example when you get far enough with the importing process an .xml file will be generated in the Content/obj/x86/Debug directory, which contains a lot of extra information the xnb generated file might not have. It can be useful to look at those .xml files and maybe even extract useful information out of those. For us it worked not so well with some easy to get information like tangents (they are just missing), but it contained all the CAT bone information on the other hand. Still good to know ^^
So we are back by converting FBX into our own format ourselves (not sure if I will write a native tool with the FBX SDK or just PInvoke from C# yet ^^). For anyone interested, there are some cool projects out there using the FBX SDK, for example this FBXViewer is a nice one, it worked out of the box with everything I had thrown at it (as opposed to converting collada mess or trying the XNA content pipeline).