Material Inheritance/Overrides at the <node> Level

I have been reading the COLLADA spec and lurking this forum in preparation to write an exporter/importer for a CAD/simulation tool. I have some concerns about the way that COLLADA deals with materials at the <geometry> level.

In our CAD tool, the assembly is represented in a tree structure in which all leaf nodes reference geometry (parts). These parts can internally reference multiple materials for various groups of polygons in their geometry. In addition, the assembly tree structure can also reference materials that are inherited down the tree. These can override the materials specified in the parts. This is used by our modelers to color/texture entire assemblies regardless of the source of the parts.

My first impulse is to map the assembly structure into <node>s and the parts into <geometry> or perhaps leaf <node>s. However, this leaves me with a problem:

The COLLADA spec doesn’t seem to have any provision for representing such a materials relationship. The closest it comes is in allowing the <instance_geometry> to <bind_material>.

I think, in order to meet my requirements, COLLADA would have to allow a <bind_material> sort of element inside the <node> element.

I had the thought that I could just push the material information down to the <instance_geometry> level (so it looks right when viewed) and use the <extra> functionality to store what I need at the <node> level (in case the file is ever re-imported). However, I’d hate to extend the file format unnecessarily, and I’d like to avoid making this too complicated.

Am I missing something simple in the COLLADA spec? Is using <extra> at the <node> level the best way to deal with this if the spec doesn’t support what I need directly?

Thank you

You’re right that in Collada material properties aren’t inherited down the node graph. You could store the inherited parts in a <node>/<extra> as you suggest, but no other apps are going to do the material inheritance when working with your data.

Instead, you could convert the material representation to Collada’s form. For example, if in your format you put a red material at the root node to color an entire assembly red, you could map that behavior to Collada by creating a red material and instantiating every geometry with the red material. By converting to Collada’s form other apps will be able to read your data properly. For any material properties that aren’t represented natively in Collada, you’d still use <extra> of course.