Multi-texture, multi-UV material spec question

I noticed a bug in the Maya 1.1 exporter, and it brought up a general question about the Collada spec. An artist exported a model that has a diffuse texture map and a bump map applied, both of which have the same UV map applied. Following is a snippet of the Collada file:

    <material id="phong4SG" name="phong4SG">
        <technique profile="COMMON">
            <input semantic="TEXTURE" source="#file17-DIFFUSE"/>
            <input semantic="TEXTURE" source="#tangentShaderUtil2-BUMP"/>
        <polygons count="726" material="#phong4SG">
          <input semantic="VERTEX" source="#orcShape-Vertex"/>
          <input semantic="NORMAL" source="#orcShape-Normal"/>
          <input semantic="UV" source="#orcShape-map1"/>
          <input semantic="UV" source="#orcShape-map1"/>

106 104 114 105 105 115 107 106 116</p>

As you can see, there are no “idx” attributes on the “input” elements. The Collada spec says these are “required”, although I’ve only ever seen them under or elements, and the Maya exporter doesn’t create these at all, which is probably a bug. I was going to modify my version of the Maya plugin to export idx elements, but that results in a problem… Note that there are 4 inputs in the above polygon list, but only 3 indices per polygon vertex (as seen by the fact that there are just 9 indices in the triangle primitive below). I figured the proper solution would be something like the following:

          <input semantic="VERTEX" source="#orcShape-Vertex" idx="0"/>
          <input semantic="NORMAL" source="#orcShape-Normal" idx="1"/>
          <input semantic="UV" source="#orcShape-map1" idx="2"/>
          <input semantic="UV" source="#orcShape-map1" idx="2"/>

Now my code can assume there are 3 indices per polygon because the highest index is “2”. The spec doesn’t seem clear on whether this would be a valid sequence – can more than one input element refer to the same idx, or does this violate the intent of the specification? The only alternative would be to create additional sources, which is rather inefficient as it requires extra indices, and I’m under the impression that arrays cannot be shared between sources, so you’d have to duplicate the arrays as well. This also loses the useful information that the source data is actually the same for both inputs.

The “multitexture.xml” example from “EQUINOX-3D” handles this issue via the inefficient source duplication method. It creates 3 full copies of the identical UV array, one for the COMMON profile, and two for the EQUINOX-3D profile, with 2 extra sets of identical indices as well. The file is almost two times larger than it needs to be.

Should the “COMMON” profile of the Collada spec include a standard way of dealing with multi-texture materials that may have unique or shared sets of UVs?

Jason Hoerner
Technical Director
Heavy Iron Studios

P.S.: What’s the difference between “TEXCOORD” and “UV”?
P.S.S.: There appears to be another bug in the Maya exporter – when I have a material that has two textures with different UV’s, it exports both sets of UVs, but references only the first set of UVs, and only exports one set of indices:

    <material id="phong1SG" name="phong1SG">
        <technique profile="COMMON">
            <input semantic="TEXTURE" source="#layeredShader1-DIFFUSE"/>
            <input semantic="TEXTURE" source="#file5-AMBIENT"/>
        <source id="pPlaneShape2-map1">  (first set of UVs here)
        <source id="pPlaneShape2-edges">  (second set of UVs here)
        <polygons count="100" material="#phong1SG">
          <param name="DOUBLE_SIDED" type="bool" flow="OUT">true</param>
          <input semantic="VERTEX" source="#pPlaneShape2-Vertex"/>
          <input semantic="NORMAL" source="#pPlaneShape2-Normal"/>
          <input semantic="UV" source="#pPlaneShape2-map1"/>
          <input semantic="UV" source="#pPlaneShape2-map1"/>  (should be second set!)

0 0 0 1 1 1 12 2 12 11 3 11</p>  (quad -- should be 16 indices, not 12)

That’s a bug in the specification. The “idx” attribute is only required on inputs of collation elements that use

or <v> elements.

Yes it’s a known bug in the Maya plug-in.

Yes this is right (except a that “UV” should be “TEXCOORD” for the semantic). You can share inputs if they are going to supply the same values. In the Remarks section of each of the collation elements: lines, polygons etc., the spec says that you can compress inputs like this. It seems you understood it okay but perhaps you didn’t find it written in the section you were expecting? Can you give me an example of how this can be written more clearly for you?

This one confused me too :). My understanding is that while “TEXCOORD” refers to the standard S and T coordinates (what some people unfortunately call “UV’s”), whereas “UV” actually refers to the inherant surface paramaterization. So, for instance, a NURBS patch has UV coordinates that run along the surface. You can slap a texture projection onto that and generate whatever TEXCOORDS you like, but the patch itself still goes the same way.

As for the rest of your comments, I think Marcus answered them. We are working on fixing those bugs. Thanks for helping identify them!

No, it doesn’t. As Lilli pointed out, UV and TEXCOORD (S and T) are completely different beasts.
multitexture.xml has an object that was created via a revolve operation. The revolve tool creates UV parameters (U is along the rotation direction, V is along the profile spline).
U and V are tied to the geometry.

After that, a texture was added to the object that uses UV texture mapping (as opposed to planar, cylindrical etc.).
Even with UV texture mapping U/V and S/T are only identical if there is no scaling, offset, repeat, or swap (S = T, U = V).
S and T (TEXCOORDS) are tied to a geometry and a specific texture-mapper (there’s one for each texture of each material of each geometry/shading group) and geometry.

Both the UV parameters and the texture coordinates are saved, so when you load the file back, you can re-map textures with UV-mapping.
Both textures happen to be UV-mapped with no repeats, so for each set, it happens that S = U and T = V, but it could be S = U2 and T = V5, or one of the textures could be mapped with X-Y projection, so there would be no relationship between U/V and S/T.