[x3d-public] Future of MultiTexture within X3D 4.x line

[Michalis Kamburelis]

Hi,

Doug asked me today on teleconference "how does MultiTexture play with new
materials' fields / nodes in X3D 4.0".

I am not satisfied with the answer I gave, so let me expand on it a bit :)

A short version:
- The X3D 4.0 remains backward-compatible with X3D 3 in all its
MultiTexture handling.
- In the future X3D 4.x, I dream to simplify X3D MultiTexture node,
deprecating *some* of its current options.

Long version, with reasons:

1. In X3D 4.0, the way I wrote my PBR changes, it's all backward-compatible
and I didn't even deprecate any aspect of MultiTexture.

- So you can use "MultiTexture" node inside "Appearance.texture" field, as
in X3D 3. And it will work as before.

- In particular the "MultiTextureCoordinate" and "MultiTextureTransform"
then provide texture coords/transformations in the same way as before: the
order of textures in "MultiTexture" is just expected to match the order
"MultiTextureCoordinate" and "MultiTextureTransform" children. The
"mapping" field inside coordinates/transforms doesn't matter. This is
explicitly written with new next at these nodes.

- The texture (MultiTexture or any other) affects diffuse color, if you
place it in Appearance.texture, and Appearance.material is a Phong Material
(with diffuseTexture = NULL). Thus Appearance.texture field in general
still makes perfect sense, it can play the role of Material.diffuseTexture
/ PhysicalMaterial.baseTexture / UnlitMaterial.emissiveTexture.

- Note that you cannot place "MultiTexture" node inside material's
"xxxTexture" fields. Because I suspected this would make implementations
complicated (it certainly would complicate CGE implementation) and there is
not much demand for MultiTexture anymore (see my point 2 below) -- so it
would be bad to introduce something complicated to implement.

2. My way of thinking about MultiTexture future (in X3D 4.1 and onward)
goes like this:

- In the ideal world, MultiTexture is just a way to express "simple
arithmetic operations on textures". E.g. you have a texture slot, but
instead of a single image, you would like to place there 3 textures, with
equation "(A + B) * C". You can think of simple arithmetic operations, or
about Photoshop/GIMP image layers.

- Unfortunately, existing MultiTexture spec tries to do much more, and it
somewhat fails. I wrote about my issues with MultiTexture on
https://castle-engine.io/x3d_multi_texturing.php . It got more complicated
than the above idea ("(A + B) * C" or Photoshop/GIMP image layers). It
copied various things from old OpenGL fixed-function rendering API, and
some of it doesn't map nicely to X3D.

    E.g. source="SPECULAR" says to use """The texture argument is the
specular color interpolated from vertex components during Gouraud
shading."""

   Which is very not useful. Browsers don't have to go Gouraud shading
(Most browsers now allow both Phong and Gouraud shading). And we have new
lighting models (physical) and the new textures (specularTexture). So using
""specular color interpolated from vertex components during Gouraud
shading.""" was already not appropriate in X3D 3, and admittedly it's even
less useful in X3D 4.

- MultiTexture, even limited to core idea ("(A + B) * C" or Photoshop/GIMP
image layers) is still *not* a very important feature. E.g. glTF doesn't
have anything equivalent, and look how visually complicated stuff they are
doing. In glTF, as in X3D 4.0, the usual way to use many textures is to
place each one in the appropriate (different) xxxTexture slot.

3. So, my ideal course forward:

- We deprecate *some parts* of MultiTexture.

    I would like at some point to deprecate "MultiTexture.function",
"MultiTexture.source", and also deprecate *some* allowed modes.

   The point is to remove stuff that is complicated / not clearly
specified. And leave *only* the stuff that performs the use-case I
described above as "(A + B) * C" or Photoshop/GIMP image layers. The rest
of things should go.

- Note that MultiTextureCoordinate and MultiTextureTransform are absolutely
OK, I have no desire to deprecate or simplify them. In X3D 4.0, these nodes
are even more important, as they also provide coordinates for new textures
in materials.

Regards,
Michalis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200710/93d4b830/attachment-0001.html>