materials

I’d suggest changing the way materials are currently assigned to geometry. It doesn’t make sense to apply a material directly onto polygons, it would be more sensible to specify the material as part of the geometry instances. Currently Collada will not allow 2 geometry instances with different materials applied to each instance. At the moment you can only do this by duplicating the mesh…

maybe something along the lines of :


<node id="pCube1" name="pCube1">
  <translate sid="translate">1 0 0</translate>
  <rotate sid="rotateZ">0 0 1 0</rotate>
  <rotate sid="rotateY">0 1 0 0</rotate>
  <rotate sid="rotateX">1 0 0 0</rotate>
  <instance_geometry url="#pCube1_pCubeShape1-lib">
    <material_assignment material="lambert1" count="6"> 
      0 1 2 3 4 5
    </material_assignment> 
  </instance_geometry>
</node>

<node id="pCube2" name="pCube2">
  <translate sid="translate">-1 0 0</translate>
  <rotate sid="rotateZ">0 0 1 0</rotate>
  <rotate sid="rotateY">0 1 0 0</rotate>
  <rotate sid="rotateX">1 0 0 0</rotate>
  <instance_geometry url="#pCube1_pCubeShape1-lib">
    <material_assignment material="blinn1" count="4"> 
      0 1 2 3 
    </material_assignment> 
    <material_assignment material="phong1" count="2"> 
      4 5
    </material_assignment> 
  </instance_geometry>
</node>

where the <material_assignment> contains face indices…

That is a similar approach to how COLLADA 1.4.0 binds material and effects to geometry. The visual scene binds the material to the geometry per instance. In the world of effects and shaders, the geometry doesn’t know very much about its appearance until its instantiated for rendering.


      <node name="Box" id="Box">
        <instance_geometry url="#box">
          <bind_material>
            <technique profile="COMMON">
              <material symbol="RED" target="#redMaterial"/>
              <material symbol="BLUE" target="#blueMaterial"/>
            </technique>
          </bind_material>
        </instance_geometry>
      </node>

would that support the possibility of handling say,

  • instance1 with all faces assigned to lambert 1
  • instance2 with 5 faces assigned to lambert2, and 1 face using phong1

Without being able to look over the spec (I’ve applied to have a look) i can’t see how you’d be able to do that using that method? It seems that you must still have a material placeholder within the polygon data for that to work? In which case, it’d be limited to only being able to assign different materials to certain sets of poly faces? ie, you would be fixed to always having ‘n’ materials on mesh instances. In maya for example, you can have seperate material assignments per-face on each instance, which is why i asked…

(Or maybe i’m just missing something by not being able to see the full spec, and see it within the context of a full data file example).

From a creators point of view…

The polygon shading group(s) is as important as the texture map?

So is it possible to isolate a ‘group’ or element and have that reflected with the uv stats and referenced to the shading group allocation. In other words a simple table that not only brings the texture stuff but also references the smoothing needed for those polygons…

PS. At the moment - without going and compiling this - can I get to try it out with Max 6?

The smooth shading structure is what makes the best realtime stuff. IMO.

A designer can use that ‘split’ as a lot of geometry…

GJ

This problem has been addresed in the new COLLADA 1.4 schema with the addition of COLLADA FX and the <bind_material> element inside <instance_geometry>.

When you create geometry, you no longer specify the exact material associated with the geometry, instead you provide a symbol for the shading group (or sub-geometry) that at instance time is bound to a specific geometry.

Additionally, <bind_material> is used to bind shader parameters to information in the geometry or scenegraph - if the model contains three texcoord sets but the shader only requires one, <bind_material> is where the selection is made. If your scene contains 30 lightsources but the material only requires two light positions, <bind_material> selects which lights you are talking about.

Why do we not bind materials to polygons by index, like you suggested? Two reasons: one, because it assumes an ordering of plygononal data that is not present in the COLLADA declaration - the COLLADA implementation is free to reorder geometrical data for efficiency’s sake, which is why we try to bind elements by name rather than position. Secondly, the assumption is that you will probably want to bind material to groups of polygons at a time - shadeing groups. If you really need to you can break an N-polygon model into N shading groups to have ultimate control, but that is probably going to be an exceptional case rather than the rule. We chose to follow genreal usage patterns in the design.

I hope that helps. Have a lok at the new COLLADA 1.4 specification and feel free to post about what you find. Comments are always welcome!

  • Robin Green
    COLLADA FX Working Group Chair.