An appearance with a diffuseColor and an RGB texture should ignore the diffuseColor

[Sgeo]

Describe the bug
When an Appearance has both a Material with a diffuseColor and an ImageTexture with RGB(A) components, the diffuseColor should be ignored, as I_DRGB is not referenced when an RGB texture is in use. It currently is not.

Screenshots
The below screenshots show a globe with an RGB texture and a diffuseColor of 1 0 0. As far as I can tell, InstantReality is correct and X_ITE is incorrect

InstantReality player

X_ITE

Additional context
#38 has some discussion about this issue, however, it looks like there is a misreading of the spec as in the "Lighting 'on'" table, I_DRGB, the diffuseColor, is not used for that scenario. The English text above the table seems to incorrectly describe the effect of the table, unless I am misunderstanding the table.
The VRML spec's English description seems to agree with the table, and not with the English description in the X3D spec.

Attached are files I used for testing. The relevant files are HelloWorld and HelloWorldXITE (the other files are because I was testing a differing implementation).

DiffuseColor.zip

[create3000]

This is more likely a feature than a bug. You can colorize the texture with a specific color or change the lightness of the texture when setting the diffuseColor to specific values. To get specification conform lighting calculations set the diffuseColor to 1 1 1. Various effects can be achieved with this behavior, for instance to animate the diffuseColor from white to black to fade out the texture.

The transparency of a RGB/A texture can be changed as well, this enables X3D authors to animate the transparency of a textured object to for instance create a fade in/out effect from opaque to transparent and vice versa.

On the other hand, X_ITE uses shaders for material/lighting calculation, and the default shader is a Gouraud shader where the material/lighting calculations are in the vertex shader, and the texture is applied in the fragment shader. It is technically not possible to use the texture color as diffuseColor in the vertex shader, because texture color is first available in the fragment shader. This means that the Gouraud shader is not fully specification conform. Specification conform lighting calculation is first possible in the Phong shader, which can be selected using Browser.setBrowserOption("Shading", "PHONG") in a Script node.

[Sgeo]

Am I understanding correctly that X_ITE's behavior is an intentional deviation from the spec? I wonder if there could be an option or some optional code to enable closer conformance to the spec for being able to use pre-existing assets more smoothly (although I understand there might be performance problems determining how many channels an image actually has), or at least some documentation on intentional deviations from spec.

[jamesleesaunders]

Joining conversations up:
x3dom/x3dom#993
The same discussion is being had on x3dom.

[create3000]

It is technically not possible and as it turns out it gives the X3D author more possibilities to control the color of the texture. Indeed it should be documented, updated documentation for diffuseColor and transparency, see http://create3000.de/users-guide/components/shape/material/#fields, and http://create3000.de/users-guide/components/shape/twosidedmaterial/#fields.

[splace]

Specification conform lighting calculation is first possible in the Phong shader, which can be selected using Browser.setBrowserOption("Shading", "PHONG") in a Script node.

are you saying the Phong renderer is spec. complaint? or that it could be? (for this and using X-ITE's current engine.)

if it is, then it should be the default, x-browser differences just drive away users.

[create3000]

Phong shader cannot be the default, spec says Gouraud is. The author must select Phong shader manually. As long as the diffuseColor is (1 1 1) there is no difference to the spec, think this should be no problem.

[Sgeo]

The X3DOM thread has a discussion about why strictly following the spec is not practical: There isn't a way to determine how many channels an image has without reprocessing it directly. I'm not entirely sure how Phong vs Gourand fits into the discussion though.

There are a number of assets (especially Cybertown assets) that have non-(1 1 1) diffuseColors with RGB textures. I assume that not much care was placed into writing such a diffuseColor, because it wouldn't have been noticeable in a spec-compliant viewer. Such assets look wrong in a non-compliant viewer that always multiplies by diffuseColor, unless the asset is changed to use diffuseColor 1 1 1 everywhere that there is an RGB texture. Someone unfamiliar with these discussions may not understand why the asset looks wrong.

[Sgeo]

This comment links to prior discussion in mailing lists about this issue. I'm not entirely sure I understand the resolution:

create3000/cobweb#34 (comment)

[michaliskambi]

From Castle Game Engine / view3dscene ( castle-engine/castle-model-viewer#21 ): We also always multiply diffuse color with the texture, regardless if the texture is RGB or grayscale. We knowingly ignore the text of the specification that says to behave differently for RGB or grayscale textures.

My reasons are now listed in castle-engine/castle-model-viewer#21 , https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent and https://castle-engine.io/x3d_multi_texturing.php#section_default_texture_mode .

I'm working to make this behavior simpler in X3D 4. The reasons and text are on: https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent .

[splace]

I'm working to make this behavior simpler in X3D 4. The reasons and text are on: https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent .

as a counter point to the positive reasons to change this in the spec (also why i think it is this way).....

multiplying colours has no, real, physical meaning, so i would say how you do it has no fundamental definition, in the long run there may be unforeseen benefits to NOT doing it.

for example;

you could (and i think in a meaningful way) multiply the diffuseColor by the intensity (greyscale) of the texture.

[michaliskambi]

@splace
Multiplying component-wise RGB texture by RGB color seems to be standard in computer graphics, also outside X3D. See e.g. glTF material (baseColor texture multiplied component-wise by factor), Blender standard material, Unity standard material.

That's probably because it's trivial to understand and implement, and it gives author good flexibility. This way if you use a non-grayscale (e.g. yellow) diffuseColor, or non-grayscale texture, they will be used (instead of ignoring diffuseColor in some cases, if following X3D 3 spec precisely).

We can speculate why it was specified in VRML 2 this way (X3D spec inherited this part from VRML 2, as far as I recall). My guess is that this was a misguided attempt at optimization, in the old days someone was afraid that component-wise RGB multiplication at each texture sampling could have a negative effect on speed. (It has no measurable effect on speed, on existing GPUs). But I am just guessing here, I didn't receive an explanation about it on x3d-public mailing list either.

[michaliskambi]

P.S. Component-wise multiplication is also consistent with how we mix light RGB color with final (maybe coming from a mix of vectors or textures) surface RGB color. And this has a physical explanation, i.e. it is some approximation of what happens in reality (approximating light and surface color spectrum using 3 float values).

So it seems consistent that we mix material with texture the same way, unless we have good reasons to do otherwise:)