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

[Andreas Plesch]

Hi Michalis,

On Sat, Sep 26, 2020 at 9:55 AM Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
> 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.

Yes, hopefully everybody got a better understanding of the ideas.

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

The concern was that MultiTextureCoordinate was designed to be used
with MultiTexture, and now would have an additional role. I feel that
the MultiTexture combination modes were a result of now very outdated
OpenGL fixed functions and that MultiTexture could be a candidate to
be deprecated. In most cases it can be probably substituted by
preprocessing of textures. But I do not know if it is somewhat popular
now or ever was popular. If MultiTexture would be deprecated,
MultiTextureCoord/Transform also should be deprecated.

Would it be possible to just spec. new nodes with the same
functionality, perhaps a MFNode TextureCoordinates and
TextureTransforms node ?

The other concern was "overloading" which Don had identified as a
foreign concept in X3D sofar. But it would be easy enough to
understand, and probably also to properly define in the spec.

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

Not sure; it may be actually simpler.

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

Well, yes but the goal here would be to keep geometry 'pristine'
assuming that this means that adding a lot of fields to geometry is
not desirable.

Another option may be to use MultiTextureCoordinate in geometry (as in
the mapping approach) and list the xxxTexCoord nodes under it. Hm,
this would probably require defining xxxTextureCoordinate nodes rather
than fields. Well, using explicit names will require more
specification language in any case.

In a way, explicit=fixed field naming could be considered a special, fixed
case of the mapping approach. Say there is a default value for
diffuseTextureMapping of "diffuse", eg. the field value could be omitted. Then

texCoord MultiTextureCoordinate {
      texCoord [
        TextureCoordinate {
          mapping "diffuse"
          point [
...

would be semantically close to or perhaps equivalent to the explicit version:

diffuseTexCoord TextureCoordinate {
          point [
...

This may point to the expectation that the explicit approach is more
efficient in scene description than the mapping approach (since more
of the relationships are predetermined in the spec.).

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

Is it easier to maintain new fields in a new node, or new fields in
existing nodes ?

texMappings would be the container for all xxxTexCoords fields but it
is possible to update the value of these fields individually.

I think it would be necessary to flesh out an example to see how
things would work out.

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

Very fair. Overall I do think it is most important to come to a
conclusion (even if not perfect).

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

Here is another edge case;

What happens if the same name for a mapping is used twice, for
different texCoords ? First one wins ? Undefined ?

And another one:

What is the scope of the mapping names ? Eg. is it allowed to use the
same name for a mapping across Shapes ? In other words, would it be
useful to allow mapping across Shapes ?

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

perhaps more precise to say "match a mapping field value of any .."

>
> ( 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.'""

Sounds good.

Regards, -Andreas

>
> Regards,
> Michalis



--
Andreas Plesch
Waltham, MA 02453