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

Michalis Kamburelis michalis.kambi at gmail.com
Sun Sep 27 07:59:34 PDT 2020 

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

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

    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.

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.

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

@John:

- I initially put the deprecated TwoSidedMaterial outside of any
level, see the very bottom of
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html
.

- After talking with Don and Richard we did it differently,
TwoSidedMaterial is now on level 4, but with note "Support optional."

In effect, TwoSidedMaterial is optional, even in "Full" profile.

Regards,
Michalis

niedz., 27 wrz 2020 o 15:02 John Carlson <yottzumm at gmail.com> napisał(a):
>
> 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
>>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

More information about the x3d-public mailing list