I finally finished reading the entire spec. There’s lots of great stuff in there. I’m really happy to see the <input> stuff that allows lots of data like multiple UV sets etc to be on the geometry.
There were somethings I have questions or comments about.
The name attribute is the text string name of this element. This value must be unique within the document containing this element. Optional.
This appears on many places throughout the document. No such restriction exists in Maya on many of the items in question. That means if I export a Maya file to collada and then re-import the contents will have changed. It will not match the original file.
have 2 name attributes, “collada_name” and “original_name” or something to that effect. That would let a developer count on certain names, for example a developer might always want to find a character’s left leg by looking for the node called “left_leg” under each character. It would also allow re-importing to same tool without changing original names.
store items in the scene instead of library. I can think of a number of problems with that scheme.
the current Maya exporter sets the name to its entire path in the scenegraph separating the various parts of the path by underscores. Since underscore is a valid name character it’s impossible to figure out the original name. If the spec specified a path separator (ie, / or | or ) that like a folder separator was not allowed in names then you could figure out the original name
1 or 3 seems like viable solutions, maybe you have another.
The image element may contain a sequence of hexadecimal binary octets representing the embedded image data. These values are interpreted at pixel values according to the format attribute.
What is the format of this data? It did not seem to be specified anywhere and also what are valid types of “format”s. Without either of these being specified there is no possibility to use that information. One suggestion would be to just remove both the format and the idea that the data can be internal to the XML format. Another suggestion would be to at least specify formats but still remove the internal pixel data option. A standardized format information might be useful since it would mean not having to open the referenced image file to find out the format although unless it is mandatory it will not be much use since any program that reads collada will have to expect the format will not be there.
The inline image data though is useless without a defined formats on how to interpret it. Rather than add more burden on collada and collada complient libraries just remove it.
Textures are missing texture based U V info which is separate from the U V info on the vertices. In the past this info was generally ignored or combined into the UVs on the geometry but in today’s world of realtime shaders this information can now be used at runtime
I’m not necessarily suggesting you add this info to <texture>, I’m mostly bringing it up in reference to my other post that collada needs to export everything.
Why is this outside of camera? In fact I’m a little bit lost as the purpose of lookat, perspective, rotate, scale, skew and translate. They are listed as children of scene as well as node. It seems like they should only be part of node.
Why is the purpose of lookat? It can be expressed as a matrix. It seems like look at would only be really useful as a constraint as in “Look at the object”. Otherwise the orientation of a camera can be found from a matrix
<rotate>, <scale>, <skew>, <translate>, <matrix>
The spec doesn’t specify if these are required or not. In the interest of making the format useful it needs to specify which is required. Otherwise, someone will write a tool to read this and then have to fix it every time they used an element that turns out to be optional and therefore not used in some other collada exporter or tool.
It also needs to specify the multiple orders for all of these.
My personal preference is to remove translate, rotate, scale and skew the spec. You can usually derive them from the matrix… My #2 preference is to make them required. I’d prefer them not to be optional otherwise the problem I just mentioned comes up.
As for matrix, it too appears to be optional. I think it should be required.
My impression is that the “asset” element is mis-placed. By that I mean it does not belong in collada at all and does not match with the stated goals. Where does asset management fit in with the goals of collada? It seems like all the information listed under asset is information that would be better tracked and used by an asset management tool and not at all by collada. In the same way as we don’t put that info into any other type of file in our asset management system. The system itself stores that info, not the individual files for sounds, textures, models, video etc.
On top of which, information that might be useful to a conversion tool like unit and up_axis are burred in this element about asset management. It seems like those should be part of the <collada> element, the <collada> attributes or another element entirely.
Extra only appears under geometry. Maya for example will let me store all kinds of extra data under a node as well as under textures, materials, and other things in the scene. Extra should be put in all major elements.
The collada spec should mandate that all available extra info always be exported by any compliant collada exporter. That way if the data is not already somewhere else in the spec it will be there for developers to use.
Without these features each time someone needs info not in the spec they will be required to write their own exporter. If that is the case collada would be of little benefit to most teams.