Tightening indexed attribute semantics

[lexaknyazev]

From meshes:

Client implementations must support at least two UV texture coordinate sets, one vertex color, and one joints/weights set.

Atm, spec doesn't require indexed semantic to start with 0. This leads to couple tricky cases:

{
    "meshes": [
        {
            "primitives": [
                {
                    "attributes": {
                        "POSITION": 0,
                        "TEXCOORD_1": 1,
                        "JOINTS_1": 2
                    }
                }
            ]
        }
    ]
}

1. Could UV set TEXCOORD_1 be declared without TEXCOORD_0?
2. Same question about JOINTS_1.
3. Could there be two UV sets TEXCOORD_1 and TEXCOORD_2 (let's say that material's texture info uses matching indices)?

Spec has a table with valid semantic names that start with 0, but it's not as strict as it should be, imho.
Also, we should add that JOINTS and WEIGHTS semantics must be both present or both absent.

CC @pjcozzi @bghgary @UX3D-nopper @javagl

[McNopper]

Suggest, that index has to start with 0 (no 1, 2, 3) and no "gaps" (no 0, 1, 3, 4) are allowed.

[javagl]

The description of TEXCOORD_0 as "UV texture coordinates for the first set", and the pattern "...must be of the form [semantic]_[set_index]" does not leave very much freedom here, but indeed, it could be worded more clearly.

However, I'll have to think about where this actually matters in the implementation. In the end, these are just strings. I assume that this aims at preventing implementations from doing short-sighted things like

if (!attributeKeys.contains("TEXCOORD_0")) { /* no texture coordinates here */ }

which may overlook a TEXCOORD_1, right?

[McNopper]

So, TEXCOORD_100 would be allowed?
The loaders just get simpler, when the index starts with 0 and so on.

[lexaknyazev]

There could be a corner case with undefined TEXCOORD_0, but defined TEXCOORD_1, could you evaluate its validity?

Both primitives use the same material, but the second one uses vertex colors instead of baseColorTexture.

{
    "materials": [
        {
            "pbrMetallicRoughness": {
                "baseColorTexture": {
                    "index": 0,
                    "texCoord": 0
                }
            },
            "occlusionTexture": {
                "index": 1,
                "texCoord": 1
            }
        }
    ],
    "meshes": [
        {
            "primitives": [
                {
                    "attributes": {
                        "POSITION": 0,
                        "TEXCOORD_0": 1,
                        "TEXCOORD_1": 2
                    },
                    "material": 0
                },
                {
                    "attributes": {
                        "POSITION": 3,
                        "COLOR_0": 4,
                        "TEXCOORD_1": 5
                    },
                    "material": 0
                }
            ]
        }
    ]
}

[UX3D-nopper]

In my opinion, the above glTF is invalid:

• The second primitive uses a material, which requires two texture coordinates but does only have one set.

If a material is assigned to a primitive, it is expected, that all parameters are used and finally the visual output is as expected. In my opinion it should not be allowed, that material parameters are discarded, just because the primitive does not have the required parameters.

Any exporter has to take care of this.

I have done this by hand but I think this is the way an exporter should solve this:

{
    "materials": [
        {
            "pbrMetallicRoughness": {
                "baseColorTexture": {
                    "index": 0,
                    "texCoord": 0
                }
            },
            "occlusionTexture": {
                "index": 1,
                "texCoord": 1
            }
        },
        {
            "occlusionTexture": {
                "index": 0,
                "texCoord": 0
            }
        }
    ],
    "meshes": [
        {
            "primitives": [
                {
                    "attributes": {
                        "POSITION": 0,
                        "TEXCCORD_0": 1,
                        "TEXCOORD_1": 2
                    },
                    "material": 0
                },
                {
                    "attributes": {
                        "POSITION": 3,
                        "COLOR_0": 4,
                        "TEXCOORD_0": 5
                    },
                    "material": 1
                }
            ]
        }
    ]
}

[lexaknyazev]

it should not be allowed, that material parameters are discarded, just because the primitive does not have the required parameters

I agree with this and with

index starts with 0

@pjcozzi @bghgary any objections?

[pjcozzi]

No objections.

[bghgary]

Seems reasonable to me.

[pjcozzi]

Discussed on a 3D Formats call.

• All indices for attribute semantics, must start with 0 and be continuous: TEXCOORD_0, TEXCOORD_1, etc.
• Materials can't reference to non existing attributes.

@lexaknyazev volunteered to make this explicit in this spec and to update the validator.