[x3d-public] Material textures and "mapping" field

[Michalis Kamburelis]

Thank you for the comments!

And thank you everyone for yesterday's talk too. I hope that I was
objective, I did not present "my existing design with mapping" as
something advised -- I described both advantages and disadvantages of
it, just as I described
https://github.com/michaliskambi/x3d-tests/wiki/Proposal:-Change-mapping-concept-into-a-number-of-xxxTexCoord-fields-in-geometry
and a number of other approaches. Before the talk, I was half-way sure
that we will go with a new design, and was prepared to work on it (to
encode in spec, to implement, to make examples). It was a good talk, I
think we clarified a ton of pros/cons around this issue.

To Andreas, the main question from me goes: are you OK with the
current design ("SFstring mapping" as described in the current working
draft 2)?

You're a crucial part of developing this, a lot of this stuff was
developed in our conversations, so I very value your opinion here.

I recall you voiced your "conditional approval" already, stating that
it is acceptable, however you don't feel OK with having
MultiTextureCoordinate/Transform still used. This was something I
considered earlier and explicitly decided to keep
MultiTextureCoordinate/Transform . The reasons are on
https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#the-new-mapping-field---a-summary
. In short (primary) because it allows to reUSE entire
MultiTextureCoordinate node as a whole, (secondary) because it keeps
compatibility with X3D 3.

Some more answers are below :)

Andreas Plesch <andreasplesch at gmail.com> wrote:
> The main motivation for targeting geometry was that it already has a
> texCoord field. There are other options if geometry should stay
> pristine. One which was not discussed sofar (and perhaps never will
> be) is to add another field to Shape, say a SFNode "texMappings'' with
> xxxTexCoord fields, ad xxxtextureTransform fields. This would probably
> allow for reuse of both Appearance( and Material) and geometry. Such a
> design may actually fit better the role of texCoords and transforms as
> linking material textures and geometry.

So as a sibling to "geometry" and "appearance" we would add a new
"texMapping" with a new node ("TexMappings"?) in "Shape" to link them.

Hm, my first thoughts about this are :

- That would be an additional complication.

- It would move texture coordinates outside of the geometry node,
which seems not intuitive.

- It would still have the problem that "we have another node to
maintain, and it has a *sum* of all materials' properties, so any
change to any material would also require updating TexMappings".

>
> The mapping approach has the big advantage that it is already
> implemented in castle engine.

I do not want to claim this advantage :) I mean, when implementing
"mapping" in CGE, I knew that I implement only a draft of X3Dv4 spec.
If we decide to change the spec, to something that we all agree is
better, then changing CGE implementation is not a problem :)

> > TODO
> > - need to better (more strictly) define relationships in X3D4 draft spec,
> > - need to check "edge cases" and soft-fail default conditions in each case of potentially missing content,
> > - emphasis on checking consistent matching and validation of content needed (Don will work on that),
> > - interesting compatibility with glTF attribute "TEXCOORD_1" technique lets import and conversions of glTF-to-X3D4 be relatively simple.
>
> I guess that question for implementers is then if these TODOs are
> expected to lead to changes in signatures (and functionality) in the
> current draft ?

I think the only functional change to the spec, coming from the above,
is that we decided to define "what happens if the mapping doesn't
match". That's what Don means by "soft-fail" above.

So the existing draft (
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.
"""

IOW, it is an error if there is no corresponding mapping. Yesterday we
decided to soften this condition to something like this:

"""
If the xxxTextureMapping field is not empty, but it doesn't match any
X3DSingleTextureCoordinateNode node on a list of texture coordinates,
then it behaves as if xxxTextureMapping was empty. IOW, the first tex
coordinates are used (unless no tex coordinates are present, then the
default tex coordinates are used).
"""

( This is my wording, fully aware that in the spec the English should
be less informal :) ). Same would go for transformations.

> Actually, the spec. should probably spell out the minimum number of
> texCoord sets a browser needs to support to be compliant (currently,
> the number is "as many as possible"). Perhaps the number should be 2
> as in glTF.

There are some limits on
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/interactive.html
and https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/immersive.html
already, """At least two textures displayed per node with any number
specified.""". But indeed this should be improved, as that's a prose
considering only MultiTextureCoordinate usage with MultiTexture. We
should clarify at MultiTextureCoordinate """At least two sets of
texture coordinates allowed.'""

Regards,
Michalis