[x3d-public] ... X3D4 PBR Material textures: all [X3DSingleTextureNode] vice some [X3DTexture2DNode] ?
Michalis Kamburelis
michalis.kambi at gmail.com
Sun Sep 27 07:38:22 PDT 2020
The rationale for using X3DEnvironmentTextureNode (cubemaps) and
X3DTexture3DNode (3D textures) is exactly the same as in X3D 3.
Whether the texture is inside a XxxMaterial, or whether it is in
"Apperance.texture". There's really nothing different in these
use-cases :) Especially because "Apperance.texture" behaves just like
"Material.diffuseTexture", or "PhysicalTexture.baseTexture" etc. --
following the prose on
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/
.
Cubemaps allow to use a texture coordinate mapping based on
directions. It makes sense to use them to specify diffuse, specular,
base, roughness, material variations...
Same for 3D textures. They allow to use simpler coordinate mapping. It
makes sense to use them for all the things :)
If you want example, you can take *any* existing X3D 3 example using
cubemaps or 3D textures. Well, in X3D 4, you could move this texture
to "Material.diffuseTexture".
So yes, it makes sense to allow everywhere X3DSingleTextureNode .
Note that we are here going above what glTF allows. glTF 2.0
specification only talks about 2D textures. So this is a feature of
X3D (already present in X3D 3) that we allow more texture types
(cubemaps, 3D textures), glTF doesn't allow them anywhere. Although
they are working on it in glTF I think, e.g.
https://github.com/KhronosGroup/glTF/issues/1366 .
Regards,
Michalis
niedz., 27 wrz 2020 o 06:37 Don Brutzman <brutzman at nps.edu> napisał(a):
>
> On 9/26/2020 6:18 AM, Michalis Kamburelis wrote:
> >
> > Yes to "use X3DSingleTextureNode throughout".
>
> OK, but just need to again check: do we actually want the more-specific [X3DTexture2DNode] instead for the Material/PhysicalMaterial/UnlitMaterial texture fields?
>
> I think it is good to keep all those texture fields consistent with the same node type. Your logic below regarding repeatS/repeatT/textureProperties also seems sensible.
>
> However am having some difficulty understanding why someone might want to modulate the various texture fields using any of these nodes:
>
> - X3DEnvironmentTextureNode (ComposedCubeMapTexture, GeneratedCubeMapTexture, ImageCubeMapTexture)
> - X3DTexture3DNode (ComposedTexture3D,ImageTexture3D,PixelTexture3D)
>
> Am willing to agree with what you said, mathematically seems OK so why not. Meanwhile still wondering conceptually about modifying *Material nodes with CubeMap or Texture3D nodes: why, what use case, what might it look like?
>
> Thanks for any rationale.
>
> Specification excerpts follow, first showing the two interfaces found in X3D version 4, then showing the node hierarchy.
>
> =====================================================
>
> X3D version 4, 18.3.2 X3DSingleTextureNode
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/texturing.html#X3DSingleTextureNode
>
> X3DSingleTextureNode : X3DTextureNode {
> SFNode [in,out] metadata NULL [X3DMetadataObject]
> }
> =====================================================
>
> X3D version 4, 18.3.4 X3DTexture2DNode
>
> X3DTexture2DNode : X3DSingleTextureNode {
> SFNode [in,out] metadata NULL [X3DMetadataObject]
> SFBool [] repeatS TRUE
> SFBool [] repeatT TRUE
> SFNode [] textureProperties NULL [TextureProperties]
> }
> =====================================================
>
> X3D version 4, 4.4.2.3 Interface hierarchy
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/concepts.html#InterfaceHierarchy
>
> | +- X3DTextureNode -+- MultiTexture
> | | |
> | | + X3DSingleTextureNode -+- X3DEnvironmentTextureNode -+- ComposedCubeMapTexture
> | | | +- GeneratedCubeMapTexture
> | | | +- ImageCubeMapTexture (X3DUrlObject)*
> | | |
> | | +- X3DTexture2DNode -+- ImageTexture (X3DUrlObject)*
> | | | +- MovieTexture (X3DSoundSourceNode, X3DUrlObject)*
> | | | +- PixelTexture
> | | |
> | | +- X3DTexture3DNode -+- ComposedTexture3D
> | | +- ImageTexture3D (X3DUrlObject)*
> | | +- PixelTexture3D
> =====================================================
>
>
> > I deliberately wanted to use the "only 2D" texture type for
> > normalTexture and occlusionTexture in X3D 4.0 (to make X3D
> > implementations easier). But I don't think anymore it's necessary. If
> > no X3D browser developer will object here, I'm cool with using (more
> > general) X3DSingleTextureNode type for them
> >
> > While 3D textures with normals, or cubemaps with normals, are not
> > common -> but they make sense, we should allow them.
> >
> > Note that your comment about repeatS repeatT or textureProperties is not valid.
> >
> > - We absolutely *want* to have repeatS, repeatT, textureProperties for
> > the 2D textures used with materials. And we will: since
> > X3DSingleTextureNode is the ancestor of X3DTexture2DNode. So changing
> > these fields (normalTexture and occlusionTexture) to
> > X3DSingleTextureNode is only adding more possibilities, not taking
> > away any. You can still place there "ImageTexture" and configure its
> > repeatXxx field.
> >
> > - Other (non-2D) textures also have analogous fields, most texture
> > nodes should have textureProperties, 3D texture nodes have repeatS/T/U
> > etc. And that's all good :)
> >
> > - These all properties make sense on textures. Placing textures inside
> > a material doesn't change anything here, it still makes sense to talk
> > about texture repeat, filtering etc.
> >
> > Regards,
> > Michalis
> >
> > sob., 26 wrz 2020 o 00:54 Don Brutzman <brutzman at nps.edu> napisał(a):
> >>
> >> Found a small inconsistency in X3D4 WD2 spec (while implementing the rest of "mapping" approach in X3D Schema and X3DUOM).
> >>
> >> Please look at node types in following, specifically [X3DSingleTextureNode] vs. [X3DTexture2DNode].
> >>
> >> =======================================
> >> 12.4.5 Material
> >>
> >> Material : X3DOneSidedMaterialNode {
> >> SFFloat [in,out] ambientIntensity 0.2 [0,1]
> >> SFNode [in,out] ambientTexture NULL [X3DSingleTextureNode]
> >> SFString [in,out] ambientTextureMapping ""
> >>
> >> SFColor [in,out] diffuseColor 0.8 0.8 0.8 [0,1]
> >> SFNode [in,out] diffuseTexture NULL [X3DSingleTextureNode]
> >> SFString [in,out] diffuseTextureMapping ""
> >>
> >> SFColor [in,out] emissiveColor 0 0 0 [0,1]
> >> SFNode [in,out] emissiveTexture NULL [X3DSingleTextureNode]
> >> SFString [in,out] emissiveTextureMapping ""
> >>
> >> SFNode [in,out] metadata NULL [X3DMetadataObject]
> >>
> >> SFNode [in,out] normalTexture NULL [X3DTexture2DNode]
> >> SFString [in,out] normalTextureMapping ""
> >> SFFloat [in,out] normalScale 1 [0, ∞]
> >>
> >> SFFloat [in,out] occlusionStrength 1 [0,1]
> >> SFNode [in,out] occlusionTexture NULL [X3DTexture2DNode]
> >> SFString [in,out] occlusionTextureMapping ""
> >>
> >> SFFloat [in,out] shininess 0.2 [0,1]
> >> SFNode [in,out] shininessTexture NULL [X3DSingleTextureNode]
> >> SFString [in,out] shininessTextureMapping ""
> >>
> >> SFColor [in,out] specularColor 0 0 0 [0,1]
> >> SFNode [in,out] specularTexture NULL [X3DSingleTextureNode]
> >> SFString [in,out] specularTextureMapping ""
> >>
> >> SFFloat [in,out] transparency 0 [0,1]
> >> }
> >> =======================================
> >>
> >> 18.3.2 X3DSingleTextureNode
> >>
> >> X3DSingleTextureNode : X3DTextureNode {
> >> SFNode [in,out] metadata NULL [X3DMetadataObject]
> >> }
> >> =======================================
> >>
> >> 18.3.4 X3DTexture2DNode
> >>
> >> X3DTexture2DNode : X3DSingleTextureNode {
> >> SFNode [in,out] metadata NULL [X3DMetadataObject]
> >> SFBool [] repeatS TRUE
> >> SFBool [] repeatT TRUE
> >> SFNode [] textureProperties NULL [TextureProperties]
> >> }
> >> =======================================
> >>
> >> Looks like node type for every SFNode texture field in the new Material nodes should be [X3DSingleTextureNode] rather than any as [X3DTexture2DNode]. Doubtful we'd ever want to rely on repeatS repeatT or textureProperties when modulating materials.
> >>
> >> OK to use [X3DSingleTextureNode] throughout?
>
> 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