<div dir="ltr">One more thing the proposer(s) can do to help decision makers: <div>- re-write the specs, showing editing: strikeout on old and underlined on new.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 5, 2018 at 3:23 PM, GPU Group <span dir="ltr"><<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> Only 1 browser </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">out of 6 manages to be 100% conforming to the current specification...</span>

<br></span><div>CONFIRMED I ran your test, with various browsers, and saw no consistency.</div><div>On behalf of freewrl project, I support the change as a function of web3d file version number.</div><div>ie if(version >= 4) full blend else v3.3-- specs.</div><div>-Doug</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 5, 2018 at 2:19 PM, Michalis Kamburelis <span dir="ltr"><<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>2018-03-05 16:51 GMT+01:00 GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>>:<br>
> I'll try and step into the shoes of 'those with power' and see what they are<br>
> thinking.<br>
> 1. does it break old behaviour<br>
> It sounds like we would be breaking old behavior.<br>
<br>
</span>First of all, note that you are focusing on one issue among a couple<br>
(of mostly independent ones) on my wiki. I just want to clarify that,<br>
for anyone reading :) We are discussing this aspect:<br>
<a href="https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent" rel="noreferrer" target="_blank">https://github.com/michaliskam<wbr>bi/x3d-tests/wiki/Make-RGB-<wbr>and-grayscale-textures-<wbr>treatment-consistent</a><br>
.<br>
<br>
As for test scenes:<br>
<br>
The testcase is linked on<br>
<a href="https://castle-engine.io/x3d_multi_texturing.php" rel="noreferrer" target="_blank">https://castle-engine.io/x3d_m<wbr>ulti_texturing.php</a> , with test results<br>
on various X3D browsers. It's named "9.<br>
material_color_mixed_with_text<wbr>ure_color:". The X3D in classic encoding<br>
is here:<br>
<br>
<a href="https://raw.githubusercontent.com/castle-engine/demo-models/master/multi_texturing/material_color_mixed_with_texture_color.x3dv" rel="noreferrer" target="_blank">https://raw.githubusercontent.<wbr>com/castle-engine/demo-models/<wbr>master/multi_texturing/materia<wbr>l_color_mixed_with_texture_<wbr>color.x3dv</a><br>
<br>
The X3D in XML encoding is here:<br>
<br>
<a href="https://raw.githubusercontent.com/castle-engine/demo-models/master/multi_texturing/material_color_mixed_with_texture_color.x3d" rel="noreferrer" target="_blank">https://raw.githubusercontent.<wbr>com/castle-engine/demo-models/<wbr>master/multi_texturing/materia<wbr>l_color_mixed_with_texture_<wbr>color.x3d</a><br>
<br>
As for backward compatibility:<br>
<br>
1. I initially made my proposal a few years ago, partially because the<br>
existing browsers were already *very* incompatible in this case.<br>
("Whether to replace, or multiply, texture color.") And I just tested<br>
today, on existing latest X3D browsers, and the results are different,<br>
better than a few years ago... and still incompatible. Only 1 browser<br>
out of 6 manages to be 100% conforming to the current specification...<br>
<br>
    (And I'm not counting here my own view3dscene, that does something<br>
different than the current specification deliberately.)<br>
<br>
    See the details on<br>
<a href="https://castle-engine.io/x3d_multi_texturing.php" rel="noreferrer" target="_blank">https://castle-engine.io/x3d_m<wbr>ulti_texturing.php</a> , the table cell<br>
titled "9. material_color_mixed_with_text<wbr>ure_color".<br>
<br>
    So the 1st goal of my proposition was to make this behavior more<br>
consistent in future X3D version, across all browsers.<br>
<br>
    Bottom line: The compatibility is already poor, when the existing<br>
implementations (mis)interpret the current specification in various<br>
(different) ways.<br>
<br>
2. Note that view3dscene and Castle Game Engine work like this (that<br>
is: always multiply, even for RGB textures, contradicting the X3D<br>
specification) from day one. And there was zero bugreports about this.<br>
Probably because some X3D browsers already work like this, or because<br>
all other graphic software (outside of X3D) already works like this<br>
(Unity3d materials, Blender materials... they all multiply, always).<br>
<br>
    So, let us not over-exaggerate compatibility breakage. My proposal<br>
tries to make things non-surprising for authors, and consistent across<br>
browsers. That's what spurred my initial need to fix this.<br>
<br>
3. The 2nd goal of my proposal is to increase interoperability with<br>
other software (outside X3D). Everyone else is just multiplying<br>
colors, not differentiating between RGB and grayscale textures. I<br>
mentioned already default Unity3d materials and Blender materials as<br>
example. I worked with various 3D authoring tools, and as far as I<br>
know --- no software, and no other 3D format, works like X3D<br>
specification dictates (replace RGB textures, multiply grayscale<br>
textures), at least by default. My proposal would make default X3D<br>
material behavior more consistent with others.<br>
<br>
    E.g. right now Blender exporter is not strictly correct, if we<br>
consider that Blender materials always multiply texture*color, while<br>
the exported X3D scene will not always multiply (if current X3D<br>
specification is implemented literally).<br>
<br>
Bottom line: I very much share your concern about<br>
backward-compatibility. But in this case, we do not have cross-browser<br>
compatibility anyway, right now. (And I think this lack of<br>
compatibility is because the specification behavior is both<br>
complicated for implementors, and unnecessarily limited for users.)<br>
<br>
As for X3D version: indeed I propose to change it with a major version X3D 4.0.<br>
<br>
Regards,<br>
Michalis<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>