[x3d-public] Minutes of X3D WG Meeting Wednesday 6th September 2017 [Public Release]

[Michalis Kamburelis]

2017-09-20 16:17 GMT+02:00 Roy Walmsley <roy.walmsley at ntlworld.com>:
> Texture
>
> This proposal was noted to represent a significant change. X3D currently
> uses a replacement approach, whereas the proposed method is mixing.
> Reviewing the current X3D specification, applying an 8-bit texture to a
> surface with a red material colour will result in a colour ranging from
> black to bright red. This contrasts with the application of a 24-bit texture
> to the red surface, which will replace the red colour entirely with the
> texture colours. Both these behaviours are defined in clause 17.2.2.4
> Lighting equations (see
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/lighting.html#Lightingequations).
>
> Concepts for improving the X3D standard, such as addition of a field, or
> even a new node, were put forward. It was agreed that examples showing both
> alternatives would be helpful, with screen shots from implementations. It
> was suggested that Michaelis be asked if he can supply these.

Note that I already tested how various X3D implementations handled the
"RGB texture with material color interaction". It is documented on
https://castle-engine.sourceforge.io/x3d_multi_texturing.php , test
number 9: "material_color_mixed_with_texture_color".

Results, in short: browser behavior is inconsistent. Only 1 browser
(Octaga) seems to do precisely what the X3D specification requires.
Everyone else (including my own browser, knowingly) does something
else. (Disclaimer: Doug made a lot of cool work on FreeWRL in the last
months, it's possible that FreeWRL results are now different for this
testcase, I have not tested them.)

My proposition is to change the specification rule to something really
simple: "Texture color is always multiplied by material color". (Of
course, it can be changed by shaders, multi-texturing... but default
is always to "multiply".) This has the benefits of :

- Being simple.

- It does not matter whether texture is RGB or grayscale. The
grayscale texture makes always exactly equivalent visual result as an
RGB texture with the 3 components (red = green = blue) equal on every
pixel. This makes things simpler both for humans (to understand) and
computers (to implement) :)

- This is also consistent with behavior of all default materials in
every 3D software, as far as I can tell (everyone does "mixing" by
default).

As for how to add this to the specification: my mail "[x3d-public] X3D
features missing, but desired, by a game engine"
http://web3d.org/pipermail/x3d-public_web3d.org/2017-April/006355.html
started a thread in x3d-public mailing list where we talked about this
with Doug Sanden.  In short, X3D browsers should do this:

- When X3D major version >= 4 then calculate color by always mixing
(new specification behavior).
- Otherwise, calculate color using whatever rule you were doing
previously (since almost no-one is following the X3D 3 specification
to the letter here, as my tests show).

Quoting myself:

"""
if X3D.major_version >= 4 then
  result := material.rgb * texture.rgb
else
  result := <do whatever you were doing previously, to not surprise
your own users>;
"""

Best regards,
Michalis