We’ve been discussing the difference between an interchange format and an export format. I think Collada ideally would do both jobs. To make that possible, I think there’s a necessary extension. First, here’s my premise:
To be an interchange format, Collada needs to express as much of the data as possible in a generic way (for example, vertex position as a 3d float vector is pretty universal! and animation can be a sequence of keyframes with orientation, position, and time). However, most art tools have data that embodies concepts that are not at all universal - like a modifier stack in MAX. To be an import/export format, Collada needs to support those as well. This will result in files with a lot of data that any 3D tool could read, and a lot of data in <Extra> tags that’s needed by the tool that created the file.
If Collada files are to serve as import/export files for a given art tool, they need to have -all- the data that tool requires. A lot of it will be in <Extra> tags, or tags not understood by a generic Collada parser.
If multiple art tools are to be able to use a Collada file as an interchange format, though, as much data as possible must be in common format. The problem arises when that common format isn’t really a reflection of how the generating art tool stores that data.
For example, I’m sure Collada will support data describing generic bone & keyframe-based animations. Any art tool should be able to display such animations. However, let’s say I have an art tool that generates animations by imposing physics on a hierarchical mesh. If I save that file as a Collada file, I’d like to be able to reload it and recover the data that describes the forces that drive my animations - <Extra><Force> etc. I’d expect a good art tool to put both common and tool-specific representations of the data in the same file. That way any tool could view my animations.
The problem comes when a different tool, with a different view of how to animate bones, is used to modify the file I created. Clearly, it won’t understand my <Force> tags.
To solve this, we could have an attribute or tag that claims ownership of data. This tag would declare that a section of Collada data is generated by a specific tool and is dependent on data that other tools may not recognize. In effect, it declares certain data “readonly” within a Collada file. This allows for interchange between a lot of tools.
The spec should also allow for a tool to override the ownership; if it does so, it must add a tag of its own so the original creation tool can detect that its custom data has been invalidated.
Here’s a potential way to do it:
<mesh tool=“parametricModeler” source=“sphereGen”> …
<Extra><sphereGen> <param > …
this implies that the “ParametricModeler” tool was used to describe a sphere; it’s saved as a <mesh> so other tools can display it, but that’s not its real format. If another tool modifies the mesh, it needs to tag it:
<Extra><sphereGen overridden=“PolyModeler”><param> …
so now if it’s loaded back into the ParametricModeler, it knows it can’t use the <sphereGen> representation any more.