[x3d-public] wondering about Texture mapping specified in material nodes [corrected]

Michalis Kamburelis michalis.kambi at gmail.com
Tue Sep 22 11:43:12 PDT 2020


Don,

What is missing in your proposals is the ability to reuse Material
and/or Appearance. B and C from my examples on
https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use
. You miss this feature in your approach. You miss the ability to
define a new mesh, with new topology and thus new texture coordinates,
that can reuse an existing Appearance and/or Material. If you try to
remake example B (
https://github.com/michaliskambi/x3d-tests/blob/master/pbr/enhanced_phong_material/mapping_second_shape_reusing_appearance.x3dv
) with your approach, you will not be able to write "appearance USE
MyAppearance". And it is important to be able to write it, as it
follows natural approach of "material library used by multiple meshes"
present in all 3D formats/software, mapping nicely to both what
authors expect, and what implementations can nicely optimize.

I hope to express it as clearly as I can, but I seem to be failing, as
we indeed go in circles, without mutual understanding. Hopefully we
will clear it up on Friday :)

I believe we are zeroing in on a proper consensus in our parallel
thread with Andreas. We have there a potential of satisfying the
necessary requirements (reusing Apperance/Material *and* using DEF/USE
for mapping). We would loose one feature (reusing geometry nodes
directly) but it is not critical. So, I think we'll get there to a
proper solution, that will make everyone happy :)

As for glTF: It is not about glTF. I do not have the equivalent glTF
example, although I provided links to relevant glTF prose in my
previous mail. I do not believe that glTF example would help here,
esp. if you don't read the glTF spec first. We're not strictly talking
here about "making something that maps from glTF to X3D". The design
issue is larger, we want to be able to reuse Appearance/Material,
regardless of glTF. Such reuse is a common feature of 3D
formats/software.

Talk to you on Friday. Hopefully we can clear things easier when
talking live :) I do understand your desire (avoiding SFstring
mapping), but I also need to make sure that critical feature (reusing
Appearance/Material) doesn't get lost on the way there :)

Regards,
Michalis

wt., 22 wrz 2020 o 20:20 Don Brutzman <brutzman at nps.edu> napisał(a):
>
> Thanks Michalis.  I've confirmed with Dick that he can attend Friday's X3D Working Group meeting.  We will dedicate this week's session to this topic.
>
> We have got to understand whether the information in the two approaches are the same or gapped...  am seeing plenty of "it won't work" critiques of wording, but still not seeing "here is what information is missing from the example."  So far, not a path to converged comprehension.
>
> Perhaps starting with a common glTF example, that you have already mapped to X3D4 WD2, will be good to compare?
>
> Step by step: if you can have revised "mapping" definitions suitable for specification prose ready, that will help.  We will need to define "mapping" for each of the three (or five) node types involved: Material TextureTransform TextureCoordinate (and maybe MultiTextureTransform  MultiTextureCoordinate?)
>
> It would also help address validation and quality assurance (QA) concerns if we can informally express what are the consistency rules for such relationships, so that future work can try to capture them as X3D Schematron rule checks.
>
> Also need to know whether NMTOKEN is an acceptable restriction on string labels for "mapping" field.  This is the same data type we use for DEF-USE, it is well defined.
>
> ==========================================================
> [1] X3D Tooltips: XML Data Types, NMTOKEN
>      https://www.web3d.org/x3d/content/X3dTooltips.html#XML
>
> "NMTOKEN is an XML term for Name Token. NMTOKEN is a special kind of CDATA string that must match naming requirements for legal characters, with no whitespace characters allowed. Additionally, from XML specification: disallowed initial characters for Names include numeric digits, diacritics (letter with accent or marking), the "." period character (sometimes called full stop) and the "-" hyphen character."
>
> [2] X3D Scene Authoring Hints: Naming Conventions
>      https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#NamingConventions
>
> [3] X3D Regular Expressions (regexes), XML Patterns
>      https://www.web3d.org/specifications/X3dRegularExpressions.html#XML
>
> [4] Extensible Markup Language (XML) 1.0 (Fifth Edition)
>      2.3 Common Syntactic Constructs
>      https://www.w3.org/TR/REC-xml/#sec-common-syn
>
> [5] W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes
>      3.4.4 NMTOKEN
>      https://www.w3.org/TR/xmlschema11-2/#NMTOKEN
> ==========================================================
>
>
> On 9/22/2020 1:49 AM, Michalis Kamburelis wrote:
> >
> > Don Brutzman <brutzman at nps.edu> wrote:
> >>
> >> Appreciate your patience.   Clearly we need a meeting to discuss this since we seem to be circling.
> >>
> >> I have multiple workshops to attend this week.  Looks like my first available day to meet is Friday.  Can start as early as 0700 Pacific.  Regular X3D teleconference also available 08-0930 Pacific.  This remains high priority.
> >
> > I can be at the teleconference (Friday 8 Pacific) this week. Indeed it
> > may be easier to talk in person :)
> >
> > More answers below :)
> >
> >>
> >> Reviewed again, summary: have offered more concise examples that seem to handle all of the shortfalls in the original failed alternatives.  Key details follow.
> >>
> >> a. I believe you stated as a functional definition that each of the Texture fields modify the corresponding Material - that certainly seems to be their purpose.  If any one of those fields needs to have different TextureTransform and TextureCoordinate values than the others, then it needs to be defined right there with the texture in question.  In other words, you can't have multiple texCoord values over on the geometry itself.
> >
> > Texture coordinates and transformations *do not* need to be specified
> > "near the texture". Texture coordinates in particular are dependent on
> > the mesh topology, that is why they are (and should stay) within a
> > geometry node (like IndexedFaceSet). This is already the design in X3D
> > 3, and I want to keep it, this was good (and is consistent with what
> > authoring tools expect, e.g. Blender also has texture coordinates
> > "tied" to a mesh, same as glTF).
> >
> > You can have the multiple texCoord values on a single geometry. It is
> > called multi-texturing, you place multiple texture coordinates within
> > MultiTextureCoordinate. It effectively allows each geometry node to
> > have a number of different texture coordinates. This is also something
> > that maps naturally to e.g. Blender or glTF. The way how
> > MultiTextureCoordinate works with mapping is described in the section
> > "12.2.4 Texture mapping specified in material nodes".
> >
> >>
> >> b. For the primary Appearance "texture" field and corresponding TextureTransform and corresponding geometry texCoord, there is no change implied from X3D3 (just like you have it).
> >
> > Sure. And I advocate to keep this property (allow to reuse Appearance,
> > Material and geometry) possible also with new design, with new nodes
> > and approaches. We don't want to say to authors """you can reuse
> > Appearance... ups, unless you have placed texture coordinates in
> > Material; then you cannot""".
> >
> >>
> >> c. Maximizing USE is not a design requirement per se, just helpful design when achievable.  Having distinct "mapping" fields across multiple node types does not make a node (or collection of nodes within a Shape) suddenly re-USE-able.  If any of the fields are different, including "mapping" then the nodes are different.  If they are the same, then USE is allowed.  Avoiding redefinition of MultiTexture itself by re-USE of the MultiTexture internal nodes is why my example simply used ImageTexture, case by case, with appropriate USE found in multiple places.
> >>
> >> Your Example C sidesteps this problem by overloading nodes with the same label, e.g.
> >>
> >>           TextureTransform {  # part of example A
> >>             mapping "diffuse-and-normal-mapping"
> >>             translation 0.5 0.5
> >>           }
> >>
> >>           TextureTransform {  # deliberately added to example A by example C
> >>             mapping "diffuse-and-normal-mapping"
> >>             translation 0 0
> >>           }
> >
> > It's not "sidestepping", it's exactly the purpose of the mapping
> > field. Another geometry may refer to the same mapping string. This is
> > the very purpose of this design.
> >
> > Again, it's not really new. That's how e.g. named attributes in
> > graphic APIs work.
> >
> >>
> >> d. If the field approach has the same information as other programmatic styles, then it is functionally equivalent to (glTF, Blender, Unity, whatever).  The parent-child field relationship approach is certainly in keeping with X3D3.
> >
> > Depends on what you mean by "functionally equivalent". If reusing
> > Appearance / Material / geometry becomes impossible in some cases,
> > then yes -- you can still make models that have the same look, but no
> > -- you have not preserved the original connections between authoring
> > tool concepts (like Blender materials and meshes).
> >
> > If we break the possibility of reusing Appearance / Material /
> > geometry, then we make the browser's job much harder. Optimizing
> > resource loading and rendering becomes much harder.
> >
> > Right now a browser can compare references to Material and/or
> > Appearance to know that it can reuse some OpenGL resources. Same for
> > geometry. This is a very important design feature.
> >
> > Again, this is a feature that everyone else has :) I would lament if
> > we lose this in X3D 4. E.g. glTF has this, Collada has this, Blender
> > has this. And X3D 3 has this. They all have a concept of "material
> > library" from which particular meshes use materials, and multiple
> > meshes can refer to the same material. Because this is both natural to
> > authors, and allows a natural resource optimization on the
> > implementation side.
> >
> >>
> >> e. If there is some aspect of model definition in your primary example not expressed in the field approach that I offered, please point out the gap.  My example was carefully derived step-by-step from yours, commenting each of your constructs in place when replaced by an alternative, so any logical misconception or disconnect should be isolable.  Here was the transition:
> >>
> >> # Version 1-original
> >> # Version 2-original-labeled   (simply adding DEF labels)
> >> # Version 3-fieldnames-verbose (keeping mapping fields in place, commented)
> >> # Version 4-fieldnames-terse   (same, minus comments)
> >>
> >> So, is anything missing?  I just rechecked again and all information in your original seems to be accounted for.
> >
> > As I mentioned, you missed examples B, C, D from my text on
> > https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use
> > . They present the important concept of "reuse". You have not shown
> > how to do this in your version. If you try, you will see you need to
> > essentially copy some node contents and "tweak" them, whereas in my
> > design you can just say "USE MyApperance" in the 2nd shape.
> >
> >>
> >> f. Something you haven't said explicitly but may be thinking:  even if the two approaches are functionally equivalent, it is conceivable that we might decide to forego the usual X3D parent-child node relationships in order to preserve portability of content when translating to/from glTF etc.
> >>
> >> ... in which case we might well decide to keep "mapping" fields as a more-compatible but less-validatable approach,
> >>
> >> ... in which case we need to look at how difficult animation has become when author must change many parameters simultaneously (via Script node synchronization) in order to achieve a single effect,
> >>
> >> Example underlying glTF code might be helpful to compare.  Would it help us to look at that for your Example A?
> >
> > This discussion is not about glTF, and it's not about animations.
> >
> > I do not have ready glTF files that exactly correspond to my examples,
> > but you can read glTF specification to see their possibilities.
> >
> > The important things:
> >
> > 1. a mesh can expose a number of attributes, in particular TEXCOORD_0
> > and TEXCOORD_1 (identified just by strings in JSON, which can be
> > directly used for our SFstring mapping). See
> > https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes
> > .
> >
> > 2. a material can indicate using a specific texture with a texture
> > coordinate number (0 or 1, matching to TEXCOORD_0 and TEXCOORD_1). See
> > https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#materials
> > .
> >
> > So multiple meshes can use the same material. They only need to
> > support the required number of texture coordinates. In our case, it
> > would mean they need to expose the required texture mapping values.
> >
> > So it is similar to the mapping SFstring I propose, except we changed
> > mapping to a more general SFstring while in glTF it is an integer.
> > (This change was after our discussion some time ago; initially I
> > proposed to make it SFInt32, which would map 100% to glTF).
> >
> > And I fully agree we should describe "mapping" field in the respective
> > nodes :) The necessary prose can be added easily, once we resolve this
> > discussion :)
> >
> > 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



More information about the x3d-public mailing list