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

[Michalis Kamburelis]

Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> In Michalis mapping approach, what happens if the given mapping strings do not match up, eg. do not have the proper partner ? Presumably undefined behaviour, but probably hard to validate with a stylesheet.

Indeed, the mappings should match (
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#TextureMapping
says """If the xxxTextureMapping field is not empty, it must refer to
a corresponding X3DSingleTextureCoordinateNode node on a list of
texture coordinates. """). I agree it introduces a difficulty to
validate with a stylesheet.

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.)

>
> Intuitively, it seems desirable to follow Don's explicit field naming approach, to allow for better validation and to keep with precedence of not having custom labels. This is just intuition, let's think about it.
>
> However, I think the explicit xxxTexCoord fields would need to stay in the geometry node (where it is now). This would then allow for reuse of Appearance (for example if it uses a texture catalog) for multiple geometries. But then the geometry (IFS) could not be reused with another Appearance (same officer but different uniform). I think there the solution is traditionally to indeed define a new Geometry but still reuse the 'meat' of the base Geometry, eg. the coordinate node and indices (indicating that they should perhaps be in their own node as well).

Reusing the "meat" of the geometry is quite involved, as not
everything is prepared for this:

- 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.

- 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).

>
> Another option may be to put the explicit xxxTexCoord fields in Appearance but outside of Material. Then Geometry could be shared. New Appearances would be required for different Geometries but they could still reuse the same Material with all the textures. That option may have potential but would be a departure.

But reusing Appearance is also important :) Appearance has fields like
shaders, pointProperties and more. Reusing them makes sense in X3D,
and it directly maps to reusing some OpenGL resources (OpenGL shaders)
across a number of geometries.

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.

Regards,
Michalis