Hi folks, I’ve been tasked with writing some C# code to use COLLADA as the default file format for our modelling applications. I’ve tried a number of different programs that claim to convert the .xsd file to a c# dom without success, until I upgraded to VS 2005 (from 2003) which has a working XSD.exe!
So now, after a few hacks to fix XmlTextAttribute problems (can’t directly interface to e.g. floatarray), I can load and save .dae files.
However… It would appear that the generated .net XML code is restricting me to one particular XML namespace - I can load 1.4.0 dae files if I use the dom code created from 1.4.0.XSD, but cannot load 1.3.1 dae files, nor vice-versa.
Because of this, I’m a little reluctant to press on with implementation, as I do not want to find that in x months time, COLLADA version n.m is released and I have to go through the whole .xsd -> classes process again :?
Is there a workaround to allow for multiple namespaces? (I somehow doubt it).
Does anyone have any experience or alternatives to using Microsoft’s XSD.exe program for C# code generation?
Will COLLADA be changing the namespace frequently/in the near future?
How do the Max/Maya/etc. COLLADA import/export plugins work? Can they handle all versions? If so, can they be forced to write to a particular namespace?
We have the same problem with the COLLADA DOM. The DOM is auto-generated from the schema, and 1.3.1 and 1.4+ are completely separate code libraries. You have to choose one or the other in an application. The short term answer is that 1.3.1 doesn’t matter anymore. All of the apps work with COLLADA 1.4.1 now.
If the schema changes but remains backward compatible, then that’s ok right? You can regenerate the C# bindings, but client code would still work fine. The real worry is if the schema changes in a way that breaks backward compatibility, which happened when we went from 1.3.1 to 1.4. In that case, not only would the C# bindings need to be regenerated, but the client code wouldn’t work with the new version. We also have this problem in the DOM. Although there’s no hard guarantee that the schema will remain perfectly backward compatible forever, breaking backward compatibility isn’t something the designers take lightly. I wouldn’t expect it to happen very often.
I remember this was discussed on the forums before. I think it’s a bug in Microsoft’s code. I hope someone files a bug report.
Building a managed wrapper around the DOM would be pretty painful. I wouldn’t recommend it. You could try another XML data binding tool for C# (like Liquid Tech’s tool), or use the XML support that comes with .Net. You’d have to parse some of the data yourself, but I don’t see why that should be a showstopper. I think that’s what Remi does in his COLLADA loader for XNA.
For FXComposer2 (Beta 3 - http://developer.nvidia.com/object/fx_c … _home.html), we use a managed wrapper around the DOM. It has been quite some investment to do this, and I’m not sure we would do this again. It works really well at this point, but it has been a long and painful process.
We are also tied to the DOM implementation, though in theory we could (and may) build new wrappers around different DOMs to handle different versions to 1.4
If we ever changed this approach, I’m guessing we’d use a straight XmlDocument, and parse the data ourselves; I’d personally recommend that approach to anyone.
I know the xna loader. The parsing is quiet simple (I am missing a dependency graph in the spec, does anyone know a good free visualization tool for drawing a tree view of the schema (library_geometries->geometry->mesh->…) ? ), but I have to load AND SAVE a Collada Document and I think the DOM is really useful for this. Of course a can hold the XML tree in memory and create special classes which have references to the nodes, but adding / deleting etc. has to be handled too, so this is exactly what the DOM does.