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

Andreas Plesch andreasplesch at gmail.com
Sun Sep 27 11:33:15 PDT 2020 

Hi Michalis, Don,

Let me respond first to Michalis, then to Don.

I trust the process, so whatever the final result is will be a good
outcome. That does not necessarily mean that it can be quickly
reflected and implemented in x3dom and perhaps other browsers.

See below for short responses/

On Sun, Sep 27, 2020 at 11:00 AM Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
> As for MultiTexture, MultiTextureCoordinate, MultiTextureTransform:
>
> - In the current version, MultiTexture indeed becomes "discouraged"
> (not explicitly "deprecated" anywhere, but its use-case is indeed
> narrow).
>
>     That is: While you can still use MultiTexture in
> "Appearance.texture", but it is not allowed in the xxxTexture fields in
> XxxMaterials, thus browsers don't need to implement a difficult case
> of "we have multiple textures in material, each one can be a
> MultiTexture".
>
>     I deliberately didn't want to go into discussion whether to
> deprecate MultiTexture or not in X3D 4, but I agree with Andreas that
> practically the design of this node has a number of problems. I think
> MultiTexture is used in practice though (at least I use it :) ), so it
> is not easy to "just remove it" now. I was whining about MultiTexture
> a few years ago already (
> https://castle-engine.io/x3d_multi_texturing.php ) and my thoughts
> about the future are on
> https://github.com/michaliskambi/x3d-tests/wiki/Deprecate-some-unused-and-badly-specified-MultiTexturing-specification-pieces

Makes sense to try to divide and conquer as much as possible.

> - I have a different opinion about MultiTextureCoordinate and
> MultiTextureTransform . For me, these nodes are good, and can stay,
> and they make all the sense in X3D v4 too :) They simply allow to
> "wrap" a number of tex coords (MFNode). This allows to reUSE
> MultiTextureCoordinate / MultiTextureTransform, which isn't a critical
> feature, but still it's "nice to have" (since we already have it :) ).

Yes, I understood that motivation. For a clean break and better
semantics, I think renaming those to something like
TextureCoordinate(Transform)Set, or adding such nodes, could be
considered. This would only make sense if MultiTexture would be
removed or deprecated which seems out of the question due to backward
compatibility requirements.

>     If I would design X3D from scratch, I would prefer to go with
> Andreas' idea, to just make "texCoord" field an MFNode, and abolish
> MultiTextureCoordinate. But right now, the benefits of keeping
> compatibility (thus, keeping "texCoord" as SFNode and using
> MultiTextureCoordinate) outweigh IMHO the benefits of
> removing/deprecating MultiTextureCoordinate and MultiTextureTransform.

right.

> As for mapping scope:
>
> - It is deliberately inside one Shape, and one Shape only. This allows
> to use the same mapping names in another geometry, and thus reUSE the
> Material / Appearance.

Yes, I thought that a mapping name scope which is restricted to the
Shape would be the intention. But I think it has to be spelled out in
the spec., somewhat in parallel to the DEF/USE namescoping rules.
Otherwise, authors may be tempted to try to use a mapped texCoord set
in another Shape by just referring to the name.

> - I have noted the edge-case "What happens if the same name for a
> mapping is used twice," . We should address it indeed ("first one
> wins" seems a simple enough solution).

ok.

> > On Sun, Sep 27, 2020 at 1:52 AM Don Brutzman <brutzman at nps.edu> wrote:
> >>
> >> Hi Andreas.  Thanks for steady scrutiny.
> >>
...
> >> Am becoming concerned that we are approaching "analysis paralysis" from taking this apart and putting it back together so many times.  Email helps but can also confound/confuse.
> >>

Yes, I understand, and I think Michalis is doing an outstanding job to
synthesize and communicate, much better than I could.

>From a technical point of view, PBR and multiple texture maps are
actually pretty standard concepts from what I have seen. It will be
great to have those concepts brought into X3D.

> >>
> >>
> >> Given the need to meet milestones for X3D4 in November with conference approaching rapidly, hoping we are ready to proceed and "regain speed" as a group.  Triage:
> >>
> >>
> >>
> >> a. *Go*. If you can "live with" mapping and we can make some secondary adjustments to spec for best effect, that remains preferred resolution.

Well, as indicated the mapping solution will work well. I just get
back drawn into explicit field naming when I start to consider how it
works, especially after Don brought it up as an alternative.

> >>
> >> b. *Good enough for now*.  If future design work occurs in spring and a clean revision is possible, we can consider it then and if everyone agrees that it "fixes" a problem then we can re-post to ISO in a future Committee Draft. (Contentious and complex but legal, of course really hoping we never need any such safety net).  If we find ourselves unavoidably in that position, at least we will have benefit of multiple implementations of "mapping" approach so that understanding of the issues and impacts will be very good.

To me going back does not sound very appealing but perhaps an option
for the spring.

> >>
> >> c. *Stop*.  If we simply must stomp on the brakes again, so be it.  Must achieve a working solution to glTF PBR in X3D.  As closest implementers we defer to your judgement.

I certainly would not want to be the only one who would say stop. It
is much more important to get to a solution. It is true that
implementation forces more thorough scrutiny and more questions tend
to crop up. Just as a reminder, x3dom has a glTF Inline implementation
which relies on translation to a different PhysicalMaterial node, and
a BufferGeometry node (which is a separate issue).

> >>
> >> Andreas you are also welcome to join us on call Tuesday at noon eastern, often f2f discussion lets us get to best shared understanding quickly and thoroughly.

Thanks. Let me try.

> >>
> >> Incidentally I am getting close to having all PBR "mapping" changes implemented in X3D XML Schema, DTD, Tooltips, X3DUOM, X3DJSAIL Java and X3DPSAIL Python.  If I finish Sunday then will post, but this is for implementation review and doesn't lock us down.
> >>
> >>
> >>
> >> Am looking ahead to "mapping" QA rules, can implement whatever guidance we produce in X3D Schematron.  The X3D Validator is back up, so that makes such testing accessible.  So I think we can have high-quality content by making verified X3D versions of primarily glTF examples publicly available.

It looks like schematron has enough expressive power to check for
mapping name scope rules, and uniqueness of names since it does
similar checks for DEF/USE

> >>
> >>
> >>
> >> A lot to think about!  As you pointed out, though, it is quite significant that Michalis has a working implementation in open source...

Indeed.

> >>
> >> Thanks for considering tradeoffs and best path forward.

Concerning paths forward it was helpful to clarify that a strong
emphasis on backward compatibility makes it unlikely that any feature
will be deprecated and later removed in v4 (and possibly future
versions).

Best,

-Andreas

> >>
> >>
> >> On 9/26/2020 2:21 PM, Andreas Plesch wrote:
> >>
> >> >
> >>
> >> > 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 ?
> >>
> >>
> >>
> >> possible i suppose, but there has been a lot of work to get interface hierarchy all consistently defined.
> >>
> >>
> >>
> >> one might look at MultitTexture as a form of MFNode container, holding those nodes.
> >>
> >>
> >>
> >> something we are realizing more is that it is getting very hard to "deprecate" and throw things away, because X3D3 has a large installed base and X3D4 loaders will always want to support X3D3 loading.  So getting rid of a node is not much of an economy, and may indeed may be much more trouble than it is worth to delete from specification since it might never go away internally.
> >>
> >>
> >>
> >> keeping older nodes that are less preferred seems much better, a single X3D4 implementation can handle both older and newer nodes without doing things similarly but differently twice.
> >>
> >>
> >>
> >> i suspect we are entering the age where we "discourage" certain node usage rather than "deprecate", we'll see.
> >>
> >>
> >>
> >> > 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
> >>
> >>
> >>
> >> all the best, Don
> >>
> >> --
> >>
> >> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
> >>
> >> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> >>
> >> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> x3d-public mailing list
> >>
> >> x3d-public at web3d.org
> >>
> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >>
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org



--
Andreas Plesch
Waltham, MA 02453

More information about the x3d-public mailing list