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

Michalis Kamburelis michalis.kambi at gmail.com
Sat Sep 19 01:59:21 PDT 2020


The approaches do not have the same expressive power.

- When we connect material with geometry with a named (SFString) mapping, a
different geometry may use a different texture coordinate node, but specify
the same mapping name.

    So the material and geometry are separable in this case. The mapping is
not a way to assign global identifiers to nodes, the mapping is only
resolved within each Shape, this is critical.

    This example is shown on
https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use
. It's where I show how to reuse material or appearance with the same
geometry.

    It is also closest to what glTF is doing where it has attribute names
like TEXCOORD0 .

- If we would place texture coordinate in material, as you propose, then
material and geometry would be unseparable. I show example how that would
make further reusing of materials on that wiki page.

Regards,
Michalis

W dniu sob., 19.09.2020 o 03:19 Don Brutzman <brutzman at nps.edu> napisał(a):

> OK thanks but... I read that in detail and am still not convinced.
>
>
>
> The explicit approach of named fields that I spelled out has the same
> expressive power as the indirect mapping-label approach in your writeup.
>
>
>
> It would also appear that the indirect mapping-label approach has the
> exact same limitation you describe.  Yes a combination is inseparable.  Yes
> any DEF and be re-USED but without changing the node in question.  Yes if
> you have that same parent-child information in a label field, it is
> inseparable.
>
>
>
> Given the flexibility of node children DEF/USE it seems like slight
> variations and combinations are just as possible as they are now inside all
> them many nodes which might comprise a Shape.
>
>
>
> I looked at your writeup once again but am still not seeing the
> unreachable use case.  A texture node with a pair of explicit accompanying
> fields (e.g. baseColorTexture, baseColorTextureCoordinate,
> baseColorTextureTransform) has the exact same information as those same 3
> nodes sharing a common label.
>
>
>
> If the same information is present either way, then both are possible or
> both are impossible.
>
>
>
> Labels are very error prone, difficult to validate and not how X3D usually
> works.  That is why other approach seems more appealing.
>
>
>
> If the information about node relationships is indeed different, then
> let's get clear why you think so.
>
>
>
> If information is the same, then we might restart from the other direction
> .  Can you please show what you think is a simple adequate glTF case and
> represent that.  Let's focus on once subset first, for example.
>
>
>
> The correlations between declarative and imperative can be
> subtle/confusing sometimes.  Am hoping that we can sort it out
> satisfactorily for best long-term representations.
>
>
>
> Thanks for persisting on this design issue, looking forward to complete
> clarity on this matter.
>
>
>
>
>
>
>
> On 9/18/2020 5:57 PM, Michalis Kamburelis wrote:
>
> > NPS WARNING: *external sender* verify before acting.
>
> >
>
> > This is exactly addressed in the long answer I wrote and linked
> previously on
>
> >
> https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use
> . I analyze there something even more flexible than what you propose, but
> still find it failing.
>
> >
>
> > Simply put, adding texture coordinate nodes to materials would mean that
> reusing materials / appearances is impossible. Geometry with the
> accompanying material / appearance would be an unseparable set. This would
> break an important usecase of reusing (important, because common in
> practice and also very useful for browsers to optimize rendering and
> resource loading). It would also be contrary to how materials and meshes
> are separated in all other graphic formats (glTF, Collada, even OBJ, even
> x3d 3) and software (Blender, Unity, 3dsMax ..)
>
> >
>
> > Regards,
>
> > Michalis
>
> >
>
> > W dniu sob., 19.09.2020 o 02:00 Don Brutzman <brutzman at nps.edu <mailto:
> brutzman at nps.edu>> napisał(a):
>
> >
>
> >     [corrected copy follows, apologies for prior send]
>
> >
>
> >
>
> >
>
> >     * X3D Architecture 12.4.6 PhysicalMaterial
>
> >
>
> >
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#PhysicalMaterial
>
> >
>
> >
>
> >
>
> >     1. The current "mapping" approach seems like a new/involved approach
> technique that adds a layer of indirection.
>
> >
>
> >
>
> >
>
> >     Why not a simpler design pattern similar to the rest of the scene
> graph?
>
> >
>
> >
>
> >
>
> >     Instead of a (bitmap) texture plus a string label for "mapping" that
> must appear identically on 2 additional nodes,
>
> >
>
> >
>
> >
>
> >     ============================================
>
> >
>
> >     PhysicalMaterial : X3DOneSidedMaterialNode {
>
> >
>
> >         SFColor  [in,out] baseColor                       1 1 1  [0,1]
>
> >
>
> >         SFNode   [in,out] baseTexture                     NULL
>  [X3DSingleTextureNode]
>
> >
>
> >         SFString [in,out] baseTextureMapping              ""     #
> string label points to matching labels in
>
> >
>
> >                                                                  #
> TextureCoordinate, TextureTransform
>
> >
>
> >         ...
>
> >
>
> >     ============================================
>
> >
>
> >
>
> >
>
> >     simply
>
> >
>
> >
>
> >
>
> >     ============================================
>
> >
>
> >     PhysicalMaterial : X3DOneSidedMaterialNode {
>
> >
>
> >         SFColor  [in,out] baseColor                       1 1 1  [0,1]
>
> >
>
> >         SFNode   [in,out] baseTexture                     NULL
>  [X3DSingleTextureNode]
>
> >
>
> >         SFNode   [in,out] baseTextureCoordinate           NULL
>  [X3DSingleTextureCoordinateNode]
>
> >
>
> >         SFNode   [in,out] baseTextureTransform            NULL
>  [X3DSingleTextureTransformNode]
>
> >
>
> >         ...
>
> >
>
> >     ============================================
>
> >
>
> >
>
> >
>
> >     and similarly apply this naming pattern each for each field:
>
> >
>
> >     - baseColor
>
> >
>
> >     - metallicRoughness
>
> >
>
> >     - emissiveColor
>
> >
>
> >     - normal
>
> >
>
> >     - occlusionStrength
>
> >
>
> >
>
> >
>
> >     ...so, adding some name regularization, resulting in full form
> something like:
>
> >
>
> >
>
> >
>
> >     ============================================
>
> >
>
> >     PhysicalMaterial : X3DOneSidedMaterialNode {
>
> >
>
> >         SFColor  [in,out] baseColor                       1 1 1  [0,1]
>
> >
>
> >         SFNode   [in,out] baseTexture                     NULL
>  [X3DSingleTextureNode]
>
> >
>
> >         SFNode   [in,out] baseTextureCoordinate           NULL
>  [X3DSingleTextureCoordinateNode]
>
> >
>
> >         SFNode   [in,out] baseTextureTransform            NULL
>  [X3DSingleTextureTransformNode]
>
> >
>
> >
>
> >
>
> >         SFFloat  [in,out] metallic                        1      [0,1]
>
> >
>
> >         SFNode   [in,out] metallicTexture                 NULL
>  [X3DSingleTextureNode]
>
> >
>
> >         SFNode   [in,out] metallicTextureCoordinate       NULL
>  [X3DSingleTextureCoordinateNode]
>
> >
>
> >         SFNode   [in,out] metallicTextureTransform        NULL
>  [X3DSingleTextureTransformNode]
>
> >
>
> >
>
> >
>
> >         SFColor  [in,out] emissiveColor                   0 0 0  [0,1]
>
> >
>
> >         SFNode   [in,out] emissiveTexture                 NULL
>  [X3DSingleTextureNode]
>
> >
>
> >         SFNode   [in,out] emissiveTextureCoordinate       NULL
>  [X3DSingleTextureCoordinateNode]
>
> >
>
> >         SFNode   [in,out] emissiveTextureTransform        NULL
>  [X3DSingleTextureTransformNode]
>
> >
>
> >
>
> >
>
> >         SFNode   [in,out] metadata                        NULL
>  [X3DMetadataObject]
>
> >
>
> >
>
> >
>
> >         SFFloat  [in,out] normalScale                     1      [0, ∞]
>
> >
>
> >         SFNode   [in,out] normalTexture                   NULL
>  [X3DSingleTextureNode]
>
> >
>
> >         SFNode   [in,out] normalTextureCoordinate         NULL
>  [X3DSingleTextureCoordinateNode]
>
> >
>
> >         SFNode   [in,out] normalTextureTransform          NULL
>  [X3DSingleTextureTransformNode]
>
> >
>
> >
>
> >
>
> >         SFFloat  [in,out] occlusionStrength               1      [0,1]
>
> >
>
> >         SFNode   [in,out] occlusionTexture                NULL
>  [X3DSingleTextureNode]
>
> >
>
> >         SFNode   [in,out] occlusionTextureCoordinate      NULL
>  [X3DSingleTextureCoordinateNode]
>
> >
>
> >         SFNode   [in,out] occlusionTextureTransform       NULL
>  [X3DSingleTextureTransformNode]
>
> >
>
> >
>
> >
>
> >         SFFloat  [in,out] roughness                       1      [0,1]
>
> >
>
> >         SFFloat  [in,out] transparency                    0      [0,1]
>
> >
>
> >     }
>
> >
>
> >     ============================================
>
> >
>
> >
>
> >
>
> >     This approach seems unambiguous, directly inspectable, validatable,
> and gives authors complete flexibility of DEF/USE.
>
> >
>
> >
>
> >
>
> >     What do you think?
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >     On 9/15/2020 1:51 PM, Michalis Kamburelis wrote:
>
> >
>
> >      > NPS WARNING: *external sender* verify before acting.
>
> >
>
> >      >
>
> >
>
> >      > I wrote an explanation about why xxxTextureMapping are not
> realized by DEF / USE on
> https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use
> .
>
> >
>
> >      >
>
> >
>
> >      > Please read that, it contains the reasoning, and examples that
> are possible thanks to the current design. In short, this means that you
> can naturally reuse (by DEF / USE) materials, appearances, geometries. This
> reuse is possible, because appearances and geometries are not inter-linked
> together by DEF / USE inside.
>
> >
>
> >      >
>
> >
>
> >      > It also contains counter-examples. That is, it shows how
> problematic it would be if we tried to force xxxTextureMapping (or
> something equivalent) using DEF / USE. I present there how, in various
> scenarios, reusing materials or appearances or geometries would then be
> impossible.
>
> >
>
> >      >
>
> >
>
> >      > Regards,
>
> >
>
> >      > Michalis
>
> >
>
> >      >
>
> >
>
> >      > wt., 15 wrz 2020 o 04:26 Don Brutzman <brutzman at nps.edu <mailto:
> brutzman at nps.edu> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu>>>
> napisał(a):
>
> >
>
> >      >
>
> >
>
> >      >     On 9/14/2020 1:12 PM, Michalis Kamburelis wrote:
>
> >
>
> >      >      > NPS WARNING: *external sender* verify before acting.
>
> >
>
> >      >      >
>
> >
>
> >      >      > xxxTextureMapping are not an enumerated value. There is no
> constrained set of values you can put there. The authors are free to invent
> their own names. As long as they match (that is, the section " 12.2.4
> Texture mapping specified in material nodes" is satisfied) then any value
> is OK.
>
> >
>
> >      >      >
>
> >
>
> >      >      > We talked about this :) xxxTextureMapping is just a unique
> identifier.
>
> >
>
> >      >
>
> >
>
> >      >     Sorry but it makes even less sense now.  We already have DEF
> and USE as unique identifiers.
>
> >
>
> >      >
>
> >
>
> >      >     Perhaps some examples might illustrate this?
>
> >
>
> >      >
>
> >
>
> >      >      > If we wanted to make a limited set of options, we would
> instead make xxxTextureMapping an SFInt32 field.
>
> >
>
> >      >
>
> >
>
> >      >     No need to create, that was just our trying to understand
> what you meant by mapping.
>
> >
>
> >      >
>
> >
>
> >      >      > xxxTextureMapping as a string is similar to glTF attribute
> names like TEX_COORD0, TEX_COORD1.
>
> >
>
> >      >
>
> >
>
> >      >     Haven't thought of an example yet that can't be accomplished
> by DEF/USE of nodes, rather than ID labels as references.  Again examples
> might help.
>
> >
>
> >      >
>
> >
>
> >      >      >  > Dick is wondering if booleans are appropriate as well,
> perhaps renaming them (or adding them).
>
> >
>
> >      >      >
>
> >
>
> >      >      > The booleans "xxxTextureEnabled" are not necessary, and
> would complicate the specification. Simply leaving the "xxxTexture" = NULL
> is a clear information that a texture doesn't exist. There's no point in
> adding an additional field to "turn off" a non-NULL texture. Neither glTF
> or other formats I know about need an additional "xxxEnabled" boolean.
>
> >
>
> >      >
>
> >
>
> >      >     sounds good on that point, thanks.
>
> >
>
> >      >
>
> >
>
> >      >      > Regards,
>
> >
>
> >      >      > Michalis
>
> >
>
> >      >      >
>
> >
>
> >      >      >
>
> >
>
> >      >      > pon., 14 wrz 2020 o 19:19 Don Brutzman <brutzman at nps.edu
> <mailto:brutzman at nps.edu> <mailto:brutzman at nps.edu <mailto:
> brutzman at nps.edu>> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu>
> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu>>>> napisał(a):
>
> >
>
> >      >      >
>
> >
>
> >      >      >     While looking at the following, it seems like accepted
> enumeration values for the *Mapping strings (xxxTextureMapping fields) are
> not provided.
>
> >
>
> >      >      >
>
> >
>
> >      >      >     [1] X3D4 Architecture, 12.2.4 Texture mapping
> specified in material nodes
>
> >
>
> >      >      >
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#TextureMapping
>
> >
>
> >      >      >
>
> >
>
> >      >      >      > The X3DOneSidedMaterialNode and descendants
> (Material, PhysicalMaterial, UnlitMaterial) introduce a number of fields to
> modify material parameters using textures. They are consistently defined by
> a pair of fields like this:
>
> >
>
> >      >      >      >
>
> >
>
> >      >      >      >   SFNode   [in,out] xxxTexture        NULL
>
> >
>
> >      >      >      >   SFString [in,out] xxxTextureMapping ""
>
> >
>
> >      >      >      >
>
> >
>
> >      >      >      > The field xxxTexture indicates a texture node.
>
> >
>
> >      >      >      >
>
> >
>
> >      >      >      > The xxxTextureMapping determines the texture
> coordinates and texture coordinates transformation for given texture
> xxxTexture.
>
> >
>
> >      >      >      >
>
> >
>
> >      >      >      > The corresponding texture coordinate and texture
> coordinate transformation nodes have a field mapping that will match the
> value of the xxxTextureMapping field. See the
> X3DSingleTextureCoordinateNode and X3DSingleTextureTransformNode
> definitions.
>
> >
>
> >      >      >      >
>
> >
>
> >      >      >      > Multiple textures may use the same texture
> coordinates and their transformations. For example, it is common that both
> normalTextureMapping and diffuseTextureMapping are equal, if the graphic
> artist prepared both normalTexture and diffuseTexture simultaneously,
> assuming the same mapping.
>
> >
>
> >      >      >
>
> >
>
> >      >      >     and
>
> >
>
> >      >      >
>
> >
>
> >      >      >     [2] X3D4 Architecture, 12.4.5 Material
>
> >
>
> >      >      >
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#Material
>
> >
>
> >      >      >
>
> >
>
> >      >      >      >   SFString [in,out] ambientTextureMapping     ""
>
> >
>
> >      >      >      >
>
> >
>
> >      >      >      >   SFString [in,out] diffuseTextureMapping     ""
>
> >
>
> >      >      >      >
>
> >
>
> >      >      >      >   SFString [in,out] emissiveTextureMapping    ""
>
> >
>
> >      >      >      >
>
> >
>
> >      >      >      >   SFString [in,out] occlusionTextureMapping   ""
>
> >
>
> >      >      >      >
>
> >
>
> >      >      >      >   SFString [in,out] shininessTextureMapping   ""
>
> >
>
> >      >      >      >
>
> >
>
> >      >      >      >   SFString [in,out] specularTextureMapping    ""
>
> >
>
> >      >      >
>
> >
>
> >      >      >     Dick is wondering if booleans are appropriate as well,
> perhaps renaming them (or adding them).
>
> >
>
> >      >      >
>
> >
>
> >      >      >         SFBool [in out]  ambientTextureEnabled TRUE
>
> >
>
> >      >      >         ...
>
> >
>
> >      >      >         SFBool [in out] specularTextureEnabled TRUE
>
> >
>
> >      >      >
>
> >
>
> >      >      >     Please advise what are candidate values for these
> strings.  Thanks!
>
> >
>
> >     all the best, Don
>
> >
>
> >     --
>
> >
>
> >     Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu <mailto: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
>
> >
>
>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200919/b3a4c713/attachment-0001.html>


More information about the x3d-public mailing list