[x3d-public] wondering about Texture mapping specified in material nodes [corrected]
Don Brutzman
brutzman at nps.edu
Fri Sep 18 17:00:19 PDT 2020
[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>> 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>>> 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
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