We are aware that some applications does have problems importing XSI generated COLLADA files. We cannot agree more with you that it’s a very unfortunate situation.
What happen in those cases, and it’s always the same story, is that the implementers of those application specific COLLADA importers often did not code their importer by looking at the COLLADA spec. They coded it based strictly on COLLADA file exported form 3dsMax. As a result, they support only a subset of what’s totally legal in COLLADA and worst than that, they often make assumption that elements in the file (id, names, hierarchy, etc.) will be exactly as 3dsMax does export them and if they don’t, the import fails.
This is especially true with transform stacks. Even if XSI has a very simple and documented transform stack, it’s not the same as the 3dsMax one and problem can occur with implementations that supports only the 3dsMax flavour of COLLADA. One cannot expect all applications to standardize on a give transformation stack so that’s why COLLADA itself allows for very arbitrary transform stack representation to enable every application to represent their transform stack in a lossless fashion. So, that’s what we do, we express our transform stack, which is different from the 3dsMax one, in COLLADA, and it’s completely valid. A thorough importer implementer would detect if a given transform stack is compatible with his application and if it isn’t, he would evaluate and bake the transform into his own transform stack. That’s what we do. We support every arbitrary transform stack at import.
Additionally, we do make sure that the COLLADA files exported from XSI are valid. We validate our file against the COLLADA schema and we also run the Coherency Test so, you can be insured that when you export a COLLADA file from XSI, it’s valid. You can run the coherency test and COLLADA schema validation on your own file by using the COLLADA Refinery if you want: http://sourceforge.net/projects/colladarefinery If you encounter issues please do send them our way, we do care and fix those issues.
To help solve this complex situation, we do put a lot of hope in the COLLADA Conformance Test that Khronos is developing; project into which we’re participating. With that test, to be able to be considered COLLADA Conformant, applications will have to support more then the 3dsMax subset. But we’re not sitting there and waiting for that Conformance Tests to come out. We did participate to the Intel Plug Fest and we had great success of interoperability with the companies that were present. We tested our plugin with the next gen 3dsMax and Maya plugins (not implemented by FS btw), with SketchUp, Cinema4D, Daz, Poser, etc. and everything worked like a charm. The issues that were unveiled at that Plug Fest were fixed and released in Crosswalk 3.1 – only two month later. We do also contact personally companies with which we eared that there was issue with our valid COLLADA file to see what can be done. For instance, even if the node type=”JOINT” is optional in COLLADA and strictly there for editor display purpose, some do rely on that to implement skinning so we made their life easier by exporting it. It’s the same for the tag name issue with Papervision 3D. Tag name are optional in COLLADA and it’s a bad design to rely on that but adding support of that to make the life of Papervision 3D COLLADA import implementers easier is indeed on our todo list with high priority.
I hope that this long post does clarify things. Now you know that you can make a difference by contacting the implementers of the importer with which you have issues. You do have the proof in your hands with the Refinery Coherency Test that your file is valid and that they should be able to import it if they claim to support COLLADA.
On our side we do have plans to try to make things easier. As I mentioned, we do have the tag name issue on our todo list with a high priority and we’re also looking into an optional export of transformation stack into an equivalent simple baked matrix which should be simpler to digest for importer that can’t handle our already simple transform stack.
As far as your preset request is concerned, in the Crosswalk export and import dialog, you have a little file icon on the top right. You can save and load Crosswalk options preset with this. Is this what you’re looking for?