diffuseColor should be ignored when there's an RGB texture about view3dscene HOT 1 CLOSED

Castle Game Engine and view3dscene knowingly go against the X3D 3 specification here.

It is documented on https://castle-engine.io/x3d_multi_texturing.php#section_default_texture_mode .

We are also working to change this behavior in X3D 4. See my plans on https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent and https://github.com/michaliskambi/x3d-tests/wiki/X3D-version-4:-New-features-of-materials,-lights-and-textures (at the bottom). See my posts on x3d-public mailing list about it. Others seem to agree, at least FreeWRL author also explicitly confirmed that changing this for X3D 4 is a good idea.

Reasons are (in short -- longer reasoning on https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent ):

• Existing browsers implement it already in inconsistent manner.

• X3D specification behavior does not seem useful to anyone.

  Multiplying RGB textures with RGB material color would be more natural, and more consistent with all other software.

  E.g. if we would apply the X3D specification literally (ignore diffuseColor when texture is RGB), then the X3D files exported from Blender would not behave as Blender expects (because in Blender, color is multipled by texture, regardless if it's RGB or grayscale).

• In non-web context, detecting RGB vs grayscale is actually also troublesome. Not all image reading libraries expose information about image header. And detecting RGB vs grayscale by looking at image contents prevents the author from forcing grayscale image to be RGB.

I'm sorry, but I do not plan to fix it. It seems we have a consensus to make this bit simpler in X3D 4, and more useful to anyone :)

from view3dscene.