I tried to use the FBX SDK (2011.3.1) to load FBX files and save them as Collada files in order to be able to import FBX files in Panda3D. Unfortunately the resulting Collada files are not usable for several reasons, among them:

• There's a Maya specific extra technique

diffuse

<diffuse>
<texture texture="Map__2-image" texcoord="CHANNEL0">
<extra>
<technique profile="MAYA">
<wrapU sid="wrapU0">TRUE</wrapU>
<wrapV sid="wrapV0">TRUE</wrapV>
</technique>
</extra>
</texture>
</diffuse>

• It assigns a texcoord channel name that isn't referenced anywhere else in the file (in the previous code sample, no geometry uses "CHANNEL0"...)

• Every polygon is exported twice, a first time with a basic material (only diffuse color, specular color, etc.) and a second time with a textured material --> this doubles the number of polygons of each model without any valuable reason

Anyway, the resulting Collada file cannot be opened correctly either with OpenCOLLADA or Panda3D's "dae2egg".

Anyone has any experience on how to "fix" it and make it understandable by common and well-reputed Collada importers such as OpenCOLLADA?

• This is a big problem I have found with Collada: it's not actually that terribly useful for transporting data between arbitrary tools that claim support for it, because it's such an overgeneralized format. It can contain data of nearly any schema and still be a valid, standard-compliant Collada file that the specific importer you are using can't really handle. It's marginally more useful as a data interchange format when you have more control over the importer/exporter, or the tools happen to produce Collada you like. – Josh Jun 29 '11 at 15:16
• @Josh: At least it's human-readable, unlike closed binary formats. At least with Collada, you can make tools and scripts that can translate from one set of data to another. Interop is at least possible, even if it requires extra work. – Nicol Bolas Jul 29 '11 at 20:24

A C# tool is your friend here - you can quickly write something using the .NET System.Xml framework which iterates over the input file, spots parts you don't like, and eliminates (or tweaks) them from the document before writing it back out again. Effectively that's what XSLT does, but in practice I've always found it to be easier to write C# code to describe the transformation than to find the cryptic XSLT syntax to do the same thing.

What you need to do is look at the 'bad' cases and spot what they have in common. For example if all of the diffuse techniques which have a texture which uses texcoord="CHANNEL0", that's easy to find. You just iterate all objects, and for each object, check all of its techniques for the offending attribute. If you don't find it, add the node to an output document and move on. If you don't recognise the node, add it to the output and move on. If you do find it, don't bother to add it to the output document and it will effectively be deleted.

Spotting duplicate polygons is a little trickier however, since you'd have to analyse each pair of polygons for equivalence. Would be much simpler if you could decide on a rule, such as "I don't care about flat colored polygons, only textured polygons", then you can just discard the appropriate polygons.

However it seems very odd to me that you're actually getting duplicates out; duplication of geometry is a big no-no for obvious reasons, so I'm surprised FBX would do that. I've only ever used Collada with Maya/Max, so couldn't vouch for what FBX produces. But I'd ask, are you super doubly sure that there really isn't duplicate geometry in there in the FBX file?

• Thanks for your answer. Of course I was able to fix it in my own importer, I was just looking for someone that already encountered and fixed the exact same problem so that I could have a standard fix and maybe apply fixes for issues I haven't discovered yet. – David Aug 2 '11 at 7:46

Find or write a different exporter, or perhaps (since Collada files are just XML) use [XSLT][1] to transform the undesired data away or in to a more generalized form?

• That's sure what I'm doing, but I was looking for someone that already did that (don't reinvent the wheel, right?) – David Aug 2 '11 at 7:50