Comments on the 1.0 spec

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.

Suggestions:

  1. 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.

  2. store items in the scene instead of library. I can think of a number of problems with that scheme.

  3. 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.

<Texture>

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.

<Perspective>

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.

<lookat>

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.

<asset>

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

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.

[quote:16pwbavh]<Perspective>

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. [/quote:16pwbavh]

I guess I should take this question. In the Renderman standard, perspective is part of the full set of matrix operations. A <perspective> operator generates a 4x4 matrix that can be concatenated into the current transform. It can be used for modelling, “pyramidization” and special camera effects. It is also part of our drive to give users the full toolset - why limit ourselves to only linear or affine transforms? Sure, it could be expressed as a raw 4x4 matrix, but we’d rather give people access to clear, parametarized expressions of their transform stacks.

[quote:16pwbavh]<lookat>

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 [/quote:16pwbavh]

Again, it’s another parametarized tool for generating a matrix to append to the transform stack. Use it if it’se useful to you.

[quote:16pwbavh]<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. [/quote:16pwbavh]

As far as I can tell, they are all required. If that’s not clear then either I misunderstand our documentation or there’s a mistake. I shall check.

It also needs to specify the multiple orders for all of these.

Orders? You mean the order of application? The order of application is the order of declaration, simple as that.

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.

Our aim is to offer the full set of tools. Removing these basic linear and affine transforms just because they’re “too basic” wouldn’t help anyone. We’re trying to preserve the transform stack in as much detail as possible. Concatenating the transforms to a 4x4 raw matrix is an option you can choose to do in your exporter, but we’d rather give people the option to be a little more expressive.

Thank you for the answers.

I guess I’m still a little lost though. Why is perspective, lookat, translate, etc available under the <scene> element. I understand why they are there under the <node> element but not the <scene> element. Is <scene> just a special case of <node>? If so why do we even need <scene>

As for preserving as much info as possible, maya uses something like trans->rot pivot in->rot->rot pivot out->scale pivot in->scale->scale pivot out. If the goals is to preserve as much info as possible then it would seem expedient to add <pivotpoint> and <scalepoint>

Since I assume that every 3D package is different, the best you can do in a generic usable way is to provide a pre-baked 4x4 matrix that the 3D package provides.

I’m not suggesting that you get rid of trans/rot/scale etc, if teams want that info it’s good that it’s there. What I’m suggesting that <matrix> be required. That way using that <matrix> I can be 100% sure to get the same results I saw in my 3D package when using the data. With the <trans/rot/scale/pivot/skew> stuff I’m less likely to get it correct. As <Matrix> is not currently required in the spec as far as I can tell there would be many cases were I’d just be out of luck and not able to continue

Thanks!

COLLADA’s description of geometry tends toward a GPU friendly streaming model. This is not so much so that you can push the data directly to vertex programs in your favorite shading language, but also that stream programming has simpler data models that we can represent concisely in XML. Of course not everyone wants to represent everything in a streaming data model. We are seeing a need for more structured (chunky) data as we arrive at a representation for skinning for example.

I can take the blame for this. I wanted elements to have a single name attribute by and large for simplicity, although I saw other schemas with separate name and id attributes. In these schemas the name attribute is not unique while the id attribute is unique (for simple document fragment addressing). I conceed that COLLADA should go this route as well.