Proposal: Change mapping concept into a number of xxxTexCoord fields in geometry - michaliskambi/x3d-tests GitHub Wiki

The current X3dv4 working draft introduces a "mapping" machanism to connect textures (property of materials) with texture coordinates (property of geometry) using an SFString identifier.

This proposal changes it to a different approach, addressing the 2 notions:

  1. Avoid introducing a new mechanism to "match" things using strings. The "mapping" as a SFString would be difficult to validate.

  2. Keeps the important property that you can define new geometry that reUSEs the existing material and/or appearance nodes. This reUSE is an important property, because: it is natural for authors to think of "library of materials used by meshes", and authoring software like Blender support it explicitly too, and formats like glTF, Collada, X3Dv3, X3Dv4 with string mapping -- they all preserve this functionality.

Note: when talking with Andreas, we mixed this with another proposal, Proposal: wrap index values in a new node. Now I think it is independent. Actually the current proposal "stand on its own", reuse of geometry is already possible, even without the need for Proposal: wrap index values in a new node.

The proposal

New xxxTexCoord fields

Introduce a number of new texture coordinate fields in geometry nodes that currently expose texCoord field. This means in particular X3DComposedGeometryNode (ancestor of many geometry nodes, including IndexedFaceSet). New fields:

ambientTexCoord # used only when material is Material
diffuseTexCoord # used only when material is Material
specularTexCoord # used only when material is Material
shininessTexCoord # used only when material is Material
baseTexCoord # used only when material is PhysicalMaterial
materialRoughnessTexCoord # used only when material is PhysicalMaterial
emissiveTexCoord # useful always
normalTexCoord # useful always
occlusionTexCoord # used only when material is Material or PhysicalMaterial

We can explicitly name here one disadvantage: this introduces a complication to geometry nodes, that effectively have to account for a sum of all possible material features. So e.g.

  • baseTexCoord is present on IndexedFaceSet, just in case it is used with PhysicalMaterial (but baseTexCoord is ignored if this IndexedFaceSet is used with Material or UnlitMaterial).

  • Similarly, diffuseTexCoord is present on IndexedFaceSet, just in case it is used with Material (but diffuseTexCoord is ignored if this IndexedFaceSet is used with PhysicalMaterial or UnlitMaterial).

But make "we can live with" this disadvantage, in light of other advantages of this design.

Concern of (everyone?) is: it means that each change of material -> results in change of geometry. We're mixing material concepts inside geometry.

What to do with existing texCoord?

The existing texCoord field can remain as a fallback. That is, if your Material defines a diffuseTexture, then

A. it uses geometry.yyyTexCoord, if yyyTexCoord <> NULL

B. otherwise it uses geometry.texCoord, if texCoord is <> NULL

C. otherwise the default texture coordinates are generated, following the node's description

For primitives without explicit tex coords (like Sphere) only C applies.

This makes the design compatible with X3D 3 ("just changing X3D 3 header to X3D 4 will keep your models working"), and also allows authors to just use texCoord in simple cases (where all textures have equal tex coords).

What to do with texture transform?

What to do with texture transform? We can make a similar approach, within materials nodes or within Appearance. Putting them inside Appearance allows to have different texture transformations with the same material, so I would say to follow the same pattern as in AD 1, and add to Appearance:

ambientTextureTransform # used only when material is Material
diffuseTextureTransform # used only when material is Material
specularTextureTransform # used only when material is Material
shininessTextureTransform # used only when material is Material
baseTextureTransform # used only when material is PhysicalMaterial
materialRoughnessTextureTransform # used only when material is PhysicalMaterial
emissiveTextureTransform # useful always
normalTextureTransform # useful always
occlusionTextureTransform # used only when material is Material or PhysicalMaterial

The Apperance.textureTransform can remain as a fallback, just like geometry texCoord.

What to do with MultiTextureXxx nodes?

What to do with MultiTexture, MultiTextureCoordinate, MultiTextureTransform now? The previous approach with mapping made no changes to MultiTextureCoordinate, MultiTextureTransform. Now it seems we would "distance" ourselves from all 3 MultiXxx nodes.

This would mean

  • You can place MultiTexture only in Apperance.texture. (This is already included in working draft prose, the texture then acts as diffuse/emissive/base depending on material type.)
  • You can place MultiTextureTransform only in Apperance.textureTransform. (And only when this transform is used for MultiTexture, so also only when this transform is used for diffuse/emissive/base depending on material type.)
  • You can place MultiTextureCoordinate only in geometry texCoord. (And only when these coordinates are used for MultiTexture, so also only when these coordinates are used for diffuse/emissive/base depending on material type.)

This needs to be carefully tested whether we don't break some compatibility unintentionally.

What to do with texCoordIndex?

What to do with texCoordIndex? Do we need diffuseTexCoordIndex, specularTeCoordIndex etc.?

Answer: no, in my (Michalis) mind. We don't need diffuseTexCoordIndex, specularTeCoordIndex etc. Reasons:

  • The multi-texturing design already encoutered this question. Multiple texture coordinates are already possible in X3Dv3 with MultiTextureCoordinate. Yet they didn't need to change texCoordIndex into a "list of MFInt32, one for each texture slot". And I believe this was OK, one texCoordIndex is enough for all.

  • Looking at glTF, it doesn't expose texCoordIndex at all. Texture coordinates are always indexed just like coordinates, i.e. using coordIndex, and texCoordIndex remains empty. This suggests there's not a big use-case for it.

Examples

https://github.com/michaliskambi/x3d-tests/blob/master/pbr/enhanced_phong_material/rejected_design/proposal_specialized_texcoords_instead_of_mapping.x3dv

The above expresses the same as the mapping approach: https://github.com/michaliskambi/x3d-tests/blob/master/pbr/enhanced_phong_material/mapping_second_shape_reusing_material.x3dv