[x3d-public] wondering about Texture mapping specified in material nodes [corrected]
Michalis Kamburelis
michalis.kambi at gmail.com
Fri Sep 18 17:57:20 PDT 2020
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> 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>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200919/e0986890/attachment-0001.html>
More information about the x3d-public
mailing list