[x3d-public] ... X3D4 PBR Material textures: all [X3DSingleTextureNode] vice some [X3DTexture2DNode] ?
Don Brutzman
brutzman at nps.edu
Sun Sep 27 15:36:21 PDT 2020
On 9/27/2020 7:38 AM, Michalis Kamburelis wrote:
> So yes, it makes sense to allow everywhere X3DSingleTextureNode .
OK very good, thanks for the elaboration. Specification change applied and checked in.
I suppose the record should show that we don't hear things like "we've gone beyond glTF" very often. Has a nice ring to it! 8)
On 9/27/2020 7:38 AM, Michalis Kamburelis wrote:
>
> 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
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