[x3d-public] wondering about Texture mapping specified in material nodes [corrected]

[Andreas Plesch]

see below:

On Tue, Sep 22, 2020 at 9:30 AM Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
> Andreas Plesch <andreasplesch at gmail.com> wrote:
> >> But I don't see the proposed alternative solution as valid. If we
> >> prevent reusing Appearance or Material or geometry nodes, then we lose
> >> an important property of a model format design. (That other formats
> >> like glTF allow, and authoring tools like Blender explicitly support.)
> >
> >
> > I think gltf just allows reuse of data components of a geometry or a texture, not the complete geometry or appearance.
>
> glTF has a mechanism to reuse glTF materials (primitive links to
> material index,
> https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes
> ).
>
> And "glTF material" is probably more like "X3D appearance" than "X3D
> material". E.g. glTF material also specifies things like alpha
> blending mode and alpha cutoff (neither of which has an official
> analogy in X3D spec, but one has CGE / InstantReality extension in
> Appearance.blendMode, one has X3DOM extension in Appearance.
> alphaClipThreshold). It's not a perfect correspondence though.

ok. Complete materials can be reused in gltf.

>
> Indeed glTF doesn't have a direct mechanism to reuse whole primitive
> with a different appearance. Since it expresses indexes as a buffer
> (unlike IndexedFaceSet.coordIndex), copying the "meat" of geometry is
> easy in case of glTF.

So perhaps the design goal would be to make it easy in x3d as well ?

>
> >> Reusing the "meat" of the geometry is quite involved, as not
> >> everything is prepared for this:
> >
> >
> > Still, this is as x3d currently is designed as I understand it.
>
> Right now you can easily reuse a mesh (IndexedFaceSet) by DEF / USE in
> X3D. Like in https://github.com/michaliskambi/x3d-tests/blob/master/pbr/enhanced_phong_material/mapping_second_shape_reusing_geometry.x3dv
> , "geometry USE MyMesh". This is possible since mesh doesn't have
> direct links to a material.

Of course. I rather wanted to point out that currently in x3d you
would reuse a coordinate node, and would have to copy an index field.

> >
> >>
> >> - For example indexes are not "wrapped" in another node in an
> >> IndexedFaceSet, so they would just have to be repeated. Unless we
> >> invent a new node "Indexes { MFInt32 index }" but it would complicate
> >> the overall design, and be a significant compatibility break from X3D
> >> 3.
> >
> >
> > True, perhaps we need such a break.
>
> I think that would be a big compatibility break :) Every
> IndexedFaceSet will be broken if we require to "wrap" indexes in a new
> node. So nearly all X3D 3 models would need to be reworked into X3D 4.

Yes but it is worth considering. v3 models of course still work in v3.
The required reworking can be easily automated.

> Unless we'll allow both methods (use "SFNode coordIndexNode" if
> non-NULL, otherwise fallback to "MFInt32 coordIndex"). But this then
> complicates our spec with a "compatibility cludge".
>
> >
> >>
> >> - Also such reuse doesn't allow the browser to easily "see" that we're
> >> not reusing geometry. If a browser has geometry-specific resources
> >> (like OpenGL VBOs) that could be reused, now it can just check that 2
> >> geometry nodes have equal references, and advise the author to reUSE
> >> the geometry nodes. If we instead make direct reusing of geometry
> >> nodes impossible (and the author can only reuse the "meat") then the
> >> browser would have to make field-by-field comparison (complicated, as
> >> it should account for various geometry nodes).
> >
> >
> > not sure if thinking about implementation details should guide a design.
>
> In general, IMHO: If we make an efficient implementation of some
> common use-case hard (harder than it is in e.g. glTF, or in Blender's
> information) then I say we did a poor job :) A proper design should be
> guided by the practical capabilities of the underlying systems. All
> real-time graphic API have a concept similar to "per-vertex data",
> "texture data", "compiled shader" etc.

Hopefully a good design would also make the implementation efficient
if not easy.

> But I agree that not everything needs to be a "common use-case", we
> should limit this label to really important things.
>
> If anything, I would say that reusing geometries is not really
> critical, so maybe there's a field to improve here.
>
> But reusing materials or appearances remains critical. In this case
> it's also about authoring tools usage. For authors, reusing materials
> or appearances makes intuitive sense too. Blender exposes this feature
> directly.

Agreed. But the only requirement then is to decouple texture
coordinates from Appearance/Material (which is already the case in
v3).

>
> >> Indeed it is tricky :) I certainly see the reason for this discussion,
> >> but I don't yet see any better solution than the current mapping
> >> SFString.
> >
> >
> > I do not think gltf has a similar mapping mechanism ?
> >
>
> See my answer to Don in the nearby thread :)

Apologies, I missed that.

>
> glTF doesn't have exactly this mechanism, but it has a simplified
> version of it. In particular glTF:
>
> - limits the number of textures to 2 (but X3D 3 has already committed
> to supporting arbitrary number of texture slots with multi-texturing)
>
> - glTF doesn't allow to specify mapping names as strings, instead they
> remain just integers on one side. So just 0 or 1. I'm cool with
> changing our mapping to be integers, but this was rejected as not
> descriptive.

Well, is it then a major step to say "emissiveTexCoord" instead of
"texCoord_1" ?

> Pasting here the relevant parts:
>
> """
> The important things:
>
> 1. a mesh can expose a number of attributes, in particular TEXCOORD_0
> and TEXCOORD_1 (identified just by strings in JSON, which can be
> directly used for our SFstring mapping). See
> https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes
> .
>
> 2. a material can indicate using a specific texture with a texture
> coordinate number (0 or 1, matching to TEXCOORD_0 and TEXCOORD_1). See
> https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#materials

I think this means then saying

normalTexCoord USE="TEXCOORD_1"

where TEXCOORD_1 was previously defined for another texture (say
emissiveTexCoord).

Let's see if I can translate that to your example B:

Shape {
  appearance DEF MyAppearance Appearance {
    material DEF MyMaterial Material {
      diffuseTexture ImageTexture { url "diffuse.png" }
      normalTexture ImageTexture { url "normal-map.png" }
      specularTexture ImageTexture { url "specular.png" }
    }
  }
  geometry DEF MyMesh IndexedFaceSet {
    coordIndex [ 0 1 2 3 ]
    coord Coordinate {
      point [
        0 0 0, ...
      ]
    }
        diffuseTextureCoord DEF TEXCOORD_0 texCoord {
          point [
            0 0,
            4 0,
            4 4,
            0 4,
          ]
        }
       normalTextureCoord USE TEXCOORD_0
       specularTextureCoord DEF TEXCOORD_1 texCoord {
          point [
            0.1 0,
            40 0,
            4 40,
            0 4,
          ]
        }

    }
  }
}

# EXAMPLE B First, define one shape that defines also MyAppearance, see above.

# Then define another shape using MyAppearance.
Shape {
  appearance USE MyAppearance
  geometry IndexedFaceSet { # some different mesh
    coordIndex [ 0 1 2 3 4 5 .... ]
    coord Coordinate {
      point [
        ....
      ]
    }
    diffuseTextureCoord DEF B_TEXCOORD_0 texCoord {
          point [
...
          ]
        }
       normalTextureCoord USE B_TEXCOORD_0
       specularTextureCoordinate DEF B_TEXCOORD_1 texCoord {
          point [
...
          ]
        }

    }
  }
}

That seems to work ?

Regards, -Andreas

PS: I should check how x3dom currently does it.

> So multiple meshes can use the same material. They only need to
> support the required number of texture coordinates. In our case, it
> would mean they need to expose the required texture mapping values.
>
> So it is similar to the mapping SFstring I propose, except we changed
> mapping to a more general SFstring while in glTF it is an integer.
> (This change was after our discussion some time ago; initially I
> proposed to make it SFInt32, which would map 100% to glTF).
> """
>
> Regards,
> Michalis

--
Andreas Plesch
Waltham, MA 02453