Multi-uv support ?

[AurL]

Hi,

There are some use-cases that would require multi-uv related data in glTF assets and I wanted to ask here and have your feedbacks about it:

Let's say I have a scene with several objects, materials and textures, and I bake a single AO map that covers the whole scene. I will need to define a new UV channel for each object.
I export my scene into glTF in order to render it in a WebGL engine. The glTF specification allows meshes to have several TEXCOORDs, but if I am right, there is no property that allow to know which UV channel is used by a texture (or a material channel).

Regarding the glTF specification, what would be the most relevant place to put this data ? (We obviously don't want to read it from the shader, and it makes sense outside of a specific implementation)

Thanks for your time!

[lexaknyazev]

The glTF specification allows meshes to have several TEXCOORDs, but if I am right, there is no property that allow to know which UV channel is used by a texture (or a material channel).

You're right: there's no generic way to bind TEXCOORD_n to a specific texture, since all technique/material stuff is based on GLSL.

---

@pjcozzi @mre4ce @mlimper

Considering ongoing efforts to decouple glTF from specific shaders and provide shaderless PBR materials, do we want to address this use case in the core spec?

[lexaknyazev]

One possible way to handle multi-UVs is to change texture-related material.values properties from a plain ID to an object with two fields (example with PBR, other material extensions could be changed alike):

{
  "meshes" : {
    "mesh_id": {
      "primitives": [
        {
          "attributes": {
            "NORMAL": "accessor_id0",
            "POSITION": "accessor_id1",
            "TEXCOORD_0": "accessor_id2",
            "TEXCOORD_1": "accessor_id3"
          },
          "material": "material_id"
        }
      ]
    }
  },
  "materials" : {
    "material_id": {
      "extensions": {
        "FRAUNHOFER_materials_pbr" : {
          "materialModel" : "PBR_metal_roughness",
          "values": {
            "baseColorFactor": [ 0.5, 0.5, 0.5, 1 ],
            "metallicFactor": 0.0,
            "roughnessFactor": 0.2,
            "metallicRoughnessTexture": {
              "texture": "texture_id",
              "semantic": "TEXCOORD_1" // defaults to "TEXCOORD_0"
            }
          }
        }
      }
    }
  }
}

This approach could enable explicit UV-coords binding for each used texture, however runtime may need to allocate a separate texcoord attribute for each texture input.

[pjcozzi]

@AurL I agree this is an important use case, thanks for bringing it up.

@lexaknyazev your approach looks OK to me, but I don't follow this:

runtime may need to allocate a separate texcoord attribute for each texture input.

If I have two textures that both point to the same texture coordinates attribute, couldn't I generate a shader that just uses that attribute twice instead of duplicating the memory?

[lexaknyazev]

If I have two textures that both point to the same texture coordinates attribute, couldn't I generate a shader that just uses that attribute twice instead of duplicating the memory?

Yes, if they point to the same coordinates, it's an implementation issue:

• allocate separate attribute for each texture input and point them to the same buffer data, OR
• regenerate shaders.

[pjcozzi]

Ah, OK.

I suggest that we propose this as part of the ongoing PBR work.

[cedricpinson]

Why not calling that 'attribute' instead of 'semantic' ? because it's exactly what it links.

[pjcozzi]

@mlimper @sbtron what do you think of @lexaknyazev's proposal above, #742 (comment)?

@lexaknyazev did you see @cedricpinson's question:

Why not calling that 'attribute' instead of 'semantic' ? because it's exactly what it links.

[lexaknyazev]

Why not calling that 'attribute' instead of 'semantic' ? because it's exactly what it links.

Those uppercase tokens (both attributes: POSITION, NORMAL, TEXCOORD_0, and uniforms: MODEL, VIEW, etc) were called "semantics" in glTF 1.0.

@pjcozzi What do you think of terms here?

[mlimper]

Looks good to me!

About the term: Is this really something you would identify to be a glTF semantic? Or could we be more specific and just call it "uv_channel" or so?

[sbtron]

How about simply adding a TexCord property for each texture type? The value can be the index of the TextureCord. Having semantic or attribute will require repeating the TEXCOORD string and it can not be anything other than TEXCOORD so we can just make it explicit:

Property	Type	Range	Default Value	Space	Description
metallicRoughnessTexture	integer				The index of the texture. Texture with two components, containing the metallic-ness of the material (first component) and its roughness (second component)
metallicRoughnessTexCoord	integer		0		The set index of metallicRoughnessTexture's TEXCOORD attribute to be used for texture coordinate mapping.

Suggested changes here:
https://github.com/sbtron/glTF/blob/2.0/specification/2.0/README.md#reference-material

[lexaknyazev]

+1 for explicit reference to texCoord index, instead of string.

But I still think that nested object would be better for texture binding because:

1. It makes material object clearer implementation-wise (no need to maintain two fields for each texture).
2. Its structure could be reused by other material models, making texture binding more consistent.

[pjcozzi]

Why not calling that 'attribute' instead of 'semantic' ? because it's exactly what it links.

Those uppercase tokens (both attributes: POSITION, NORMAL, TEXCOORD_0, and uniforms: MODEL, VIEW, etc) were called "semantics" in glTF 1.0.

@pjcozzi What do you think of terms here?

These are attributes. glTF has "semantics" for well-known vertex types, just like it has semantics for well-known uniform types, which define the intended usage. This is pretty common AFAIK so I suggest to leave it.

[sbtron]

@AurL @cedricpinson it would be good to confirm the proposed approach to multi-uv in #830 meets your needs.
Essentially its adding a texCoord parameter to all the textures:
https://github.com/sbtron/glTF/tree/2.0/specification/2.0#reference-textureInfo

[pjcozzi]

Updated in #826

Also see #830

[electrowolff]

If each map can define it's own texCoord property, then what's the purpose of the TEXCOORD_0 and TEXCOORD_1 attributes? What are they supposed to be mapped to in the shader?

[stevenvergenz]

The texCoord property is an integer representing which of the TEXCOORD_* attributes to use, so you need both. YMMV though, the texCoord thing is pretty tricky to implement in some engines.

[electrowolff]

Oh I thought texCoord was an accessor index, and each map could have their own set of values. Thanks!