[x3d-public] wondering about candidate values for Texture mapping specified in material nodes

[Michalis Kamburelis]

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> 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>> 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/20200915/cfab1ed1/attachment.html>