[x3d-public] PhysicalMaterial's texture types

[Michalis Kamburelis]

>
> PhysicalMaterial’s texture type is X3DSingleTextureNode, which includes X3DEnvironmentTextureNode, which makes no sense, and X3DTexture3DNode’ which is hard to implement. I don’t think that GLTF specifies that these texture type should work, it is designed for simplicity.
>
> The same is for new X3Dv4 Material texture type.
>
> I think that X3DTexture2DNode is enough for these special textures.
>

Im my eyes, both cubemaps (X3DEnvironmentTextureNode) and 3D textures
(X3DTexture3DNode) make sense in "Material.diffuseTexture" and
"PhysicalMaterial.baseTexture"
exactly as they did for "Appearance.texture" field in X3D 3. For
consistency, it follows they should also be allowed in all
"Material.xxxTexture" and "PhysicalMaterial.xxxTexture" slots.

Use-cases:

- 3D texture allows you to apply a volume of pixels that can have
trivial texture coordinates derived from 3D positions. E.g. to apply a
noise to make a marble, or to make a fog.

- Cubemap texture allows you to make define colors based on normals,
which includes the possibility to make mirrors (colors based on
reflected vector). Like on
https://castle-engine.io/x3d_implementation_cubemaptexturing.php

I am using these features in Castle Game Engine :) Note that in both
cases, you likely want to use TextureCoordinateGenerator also.

These are the general reasons for using these textures (regardless of
X3D), so it follows we'd like to allow them in X3D most important
texture fields -- Material.diffuseTexture (if you use Phong) or
PhysicalMaterial.baseTexture (if you use PBR). And allowing them on
other texture fields is just consistent -- e.g. when you provide
colors using 3D texture to "Material.diffuseTexture", you likely want
to provide normals or specular values (if you provide them by texture
at all) using the same texture type, which means you also want to use
3D texture there.

This also follows how GPUs think about textures. Texture is just a
function to map some values (texture coordinates) into something else
(some material parameter), that you can use to render the shape. 2D
textures, 3D textures, cubemaps take different types of data, but then
their usage is very similar -- you have some input (texture coord),
you query the texture, you get a result. An implementation can mostly
just allow all GPU textures types throughout the code, at least that's
how I see it in CGE.

As for glTF only allowing 2D textures: that is true, but glTF
specification doesn't talk about other textures than 2D at all. They
did it for simplicity. In X3D, we had already invented cubemaps and 3D
textures. It would be a shame to then not use them for
"Material.xxxTexture" and "PhysicalMaterial.xxxTexture" slots. I think
it's possible that glTF will follow at some point -- they'll add
3D/cubemap textures to glTF (e.g. their image-based lighting
extensions need cubemaps, and right now invent it in isolation), and
then allow them in material fields (though I speculate here, I didn't
actually see glTF development in this area yet).

As for these texture types being harder to implement: that is true,
and, combined with the fact that 3D/cubemap texture usage is much
smaller than 2D texture usage, I understand some X3D browsers just
don't want to go there. That is why they remain in separate X3D
components, for 3D textures and cubemaps. We don't require all X3D
browsers to implement 3D/cubemap textures in "Material.xxxTexture" and
"PhysicalMaterial.xxxTexture" slots, just as we didn't require all X3D
browsers to implement 3D/cubemap textures in "Appearance.texture" in
X3D 3.

Note that I don't really treat the "Material.xxxTexture" and
"PhysicalMaterial.xxxTexture" slots as something for "special
textures". On the contrary, I treat these fields as a primary way to
use textures in X3D. This is consistent with texture usage in glTF,
Collada -- they all define textures inside material slots. I treat
"Appearance.texture" as just a historic artifact -- from simpler (X3D
3) times when people wanted the texture to only affect Phong diffuse
parameter.

I hope this helps. Discussion is absolutely most welcome. If there is
a general consensus that "we should limit these textures to 2D", I can
live with it -- and allow there 3D textures/cubemaps only as Castle
Game Engine extensions.

Regards,
Michalis