[x3d-public] X3D features missing, but desired, by a game engine

[doug sanden]

> 
> 2. Make RGB and grayscale textures treatment equal. The goal is to
> change the specification such that "grayscale texture" is for X3D
> material mixing (aka "light calculation") used the same way as "RGB
> texture with red=blue=green on all pixels".
> 
>   Current specification rule is weird for authors (it says that
> grayscale textures mix, but RGB textures replace), it is uneasy to
> implement (some image loaders do not expose the necessary information
> about the image), and it is inconsistently applied in current X3D
> implementations.

Specs > v3.3 > Table 17.2, 17.3 blending rules
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/lighting.html#t-Litcolourandalpha

I had a theory/hypothesis about how the specs table 17.2, 17.3 could end up a bit awkward: 
back in the old days when internet was just starting, and low bandwidth (remember 
dial up modems? and when 19.2kbaud was hot - big improvement over 9600?)
image files would be the last thing to show up, if ever. 
So material color was what it would thunk to while waiting. In other words,
the color would be a placeholder for image texture, in case the image file
never showed up. So 'replace' made sense -the image and color were doing the same job. 
Fancy blending modes were the last thing they were thinking of.

more.,,
In recent freewrl code there are a few lines  -currently baked in, set to non-spec, 
could be an option or f(x3d version)- that can switch to the blending style.
https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/lib/scenegraph/Component_Shape.c
Component_Shape L.856

			//modulation:
			//- for Castle-style full-modulation of texture x CPV x mat.diffuse
			//     and texalpha x (1-mat.trans), set 2
			//- for specs table 17-2 RGB Tex replaces CPV with modulation 
			//     of table 17-2 entries with mat.diffuse and (1-mat.trans) set 1
			//- for specs table 17-3 as written and ignoring modulation sentences
			//    so CPV replaces diffuse, texture replaces CPV and diffuse- set 0
			// testing: KelpForest SharkLefty.x3d has CPV, ImageTexture RGB, and mat.diffuse
			//    29C.wrl has mat.transparency=1 and LumAlpha image, modulate=0 shows sphere, 1,2 inivisble
			//    test all combinations of: modulation {0,1,2} x shadingStyle {gouraud,phong}: 0 looks bright texture only, 1 texture and diffuse, 2 T X C X D
			int modulation = 1; //freewrl default 1 (dug9 Aug 27, 2016 interpretation of Lighting specs)
			channels = getImageChannelCountFromTTI(node->appearance);

http://dug9.users.sourceforge.net/web3d/tests/29C.wrl
- visible sphere with table 17.2, 17.3, invisible with modulcaiton/use of alpha in image
http://x3dgraphics.com/examples/X3dForWebAuthors/KelpForestExhibit/SharkLefty.x3d
- has color, CPV (color per vertex) and texture

more...
Detecting grayscale image after image library has loaded the image in a generic way:
recent freewrl runs a cpu intensive test for R==G==B when loading image files, in separate loading thread
- starts with first pixel, runs till it finds a difference or end of image
- if no difference, sets number of color channels to 1 (else 3) (plus alpha). Then in above code
			channels = getImageChannelCountFromTTI(node->appearance);
returns channel count for influencing use in shader

> 
>   My implementation (Castle Game Engine) does it against the current
> specification, by default we just always multiply texture.rgb *
> material.rgb, regardless if the texture is RGB or grayscale.
> Knowingly, because the specification behavior was really
> uncomfortable, for X3D authors too. This is the one place where I
> allowed myself to knowingly go against the specification. See here for
> more details: https://castle-engine.sourceforge.io/x3d_multi_texturing.php#section_default_texture_mode
> 
>   The above page also contains tests of this feature on various
> implementations, and found it already inconsistently handled by other
> browsers.
> 
>   It seems that a simple change to the specification (treat grayscale
> textures same as RGB) would make things easier both for developers and
> for X3D authors.
>