[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