[x3d-public] wondering about Texture mapping specified in material nodes [corrected]
Don Brutzman
brutzman at nps.edu
Fri Sep 18 18:18:57 PDT 2020
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
More information about the x3d-public
mailing list