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

Sun Sep 27 06:01:18 PDT 2020

Suggestion.   Move deprecated nodes to a “high” or infinite component
level, so that new browsers, etc. won’t implement it.

On Sun, Sep 27, 2020 at 1:52 AM Don Brutzman <brutzman at nps.edu> wrote:

> Hi Andreas.  Thanks for steady scrutiny.
>
>
>
> Hope we didn't get ahead of ourselves and declare consensus too soon... we
> were carefully trying to understand and thought we understood your posted
> ideas pretty fully last Friday.
>
>
>
> Nevertheless PBR is one of the most complex things we have yet tackled as
> a group.
>
>
>
> 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.
>
>
>
> Friday we spoke together for two hours and seemed to have a good shared
> comprehension of all tradeoffs.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> A lot to think about!  As you pointed out, though, it is quite significant
> that Michalis has a working implementation in open source...
>
>
>
> Thanks for considering tradeoffs and best path forward.
>
>
>
>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200927/610423cd/attachment-0001.html>