Table of Contents:

• What is going on with multi-texturing in X3D 4.0?
• Future of MultiTexture in X3D (thoughts)
• Future of MultiTexture in X3D (actions)

What is going on with multi-texturing in X3D 4.0?

The X3D 4.0 remains backward-compatible with X3D 3 in all its MultiTexture handling.

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.

Future of MultiTexture in X3D (thoughts)

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.

Future of MultiTexture in X3D (actions)

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.