<div dir="ltr"><div>I'll try and step into the shoes of 'those with power' and see what they are thinking.</div><div>1. does it break old behaviour</div>It sounds like we would be breaking old behavior.<div>Not impossible - its been done before with version changes - but reluctantly  lots of vested interests leaning against it, the dozen or so active browser developers and their end users - would it be on the order of 100,000 active content users with 10,000,000 actively viewed scenes?. Scenes break and end users with stranded scenes may give up and say 'rather than upgrade my scenes for the new version, maybe this is a good time for me to change to different technology' and be lost forever.</div><div>My impression: it's much easier to get a new feature approved if it doesn't break old behavior by default, by a factor of  (guessing) 10;<br></div><div>if you've got a way to do it that doesn't break old, that would be a big boost.</div><div>(But having said that, view3dscene would face broken scenes if you changed to not break the other 9,000,000 scenes)</div><div>if breaking, Is there a scene-upgrader utilitly/ETL?</div><div><br></div><div>2. are other browser developers on-side</div><div>If you can round-up comments from other browser developers and submit -or even address issues raised by other browser developers beforehand- that would go a long way to speeding the process.</div><div>Especially with things that will break old scenes. Its the 10,000,000 scenes. The browser developers are kind of like representatives of all those scene owners.</div><div><br></div><div>3. is there a 'model scene' or prototype scene that we can look at the syntax, and run?</div><div>- if you've left little snippets and hints 'oh just do this or that'  its not as precise. If I try and make a scene based on hints, what if I get it wrong. I may end up spending weeks analyzing the wrong idea. </div><div>Since its a visual effect proposal, maybe a screenshot of what it should look like when rendered, would clarify the proposal.</div><div>For this particular case, how about showing what something like sharkLefty would look like.</div><div><a href="http://x3dgraphics.com/examples/X3dForWebAuthors/KelpForestExhibit/SharkLeftyIndex.html">http://x3dgraphics.com/examples/X3dForWebAuthors/KelpForestExhibit/SharkLeftyIndex.html</a><br></div><div>- it has material, imagetexture, and cpv (that is set false but can be turned on).</div><div>Or something like it where we can see permutations of the old way and compare to permutations of the new way.</div><div><br></div><div>4. timing. </div><div>- Is there a major new version in the works</div><div>- are browser devlopers opening their IDEs and upgrading test scenes for other reasons</div><div>In this case v4 is in the works, seems like good timing</div><div><br></div><div><br></div><div>Summary, for something like this where we are potentially breaking old, there's lots of permutations, not much for concrete examples and screenshots, and weak feedback from other browser developers who are busy on other priority issues for their market, I think it takes more time and effort -onus- on the part of the idea submitter(s) to do more of the ground work, to speed up the process.</div><div><br></div><div>-Doug</div><div><br></div><div>Maybe what I can do to help over in freewrl is get a 2nd implementation working with some commandline or menu option. </div><div>- I have internal #defines. But not triggering based on file version or node fields.</div><div>- I think right now freewrl is set half-way between replace and modulate, so I need to do something with options anyway</div><div>x but will take me a few weeks to get to it and do an .msi </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 5, 2018 at 3:41 AM, 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 class=""> 2018-03-05 11:12 GMT+01:00 Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>>:<br>
> If you want to change the behavior of channels (e.g. to "replace"<br>
> instead of "modulate" on all RGBA channels, or to "replace" only on<br>
> the alpha channel but modulate on RGB) then use the multi-texturing<br>
> nodes with a single texture. MultiTexture.mode field was invented<br>
> exactly to specify such thing, and it should work equally well when<br>
> you just place a single texture inside MultiTexture. Unfortunately,<br>
> the MultiTexture specification is ambiguous... but I propose how to<br>
> fix it, and also extend, on<br>
> <a href="https://castle-engine.io/x3d_multi_texturing.php" rel="noreferrer" target="_blank">https://castle-engine.io/x3d_<wbr>multi_texturing.php</a> . (My view3dcene and<br>
> Castle Game Engine already implement it, if you want to check.)<br>
><br>
<br>
</span>Maybe some examples will help to convey what I mean in the paragraph above :)<br>
<br>
If we would apply X3D specification changes that I propose on<br>
<a href="https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent" rel="noreferrer" target="_blank">https://github.com/<wbr>michaliskambi/x3d-tests/wiki/<wbr>Make-RGB-and-grayscale-<wbr>textures-treatment-consistent</a><br>
*and* on <a href="https://castle-engine.io/x3d_multi_texturing.php" rel="noreferrer" target="_blank">https://castle-engine.io/x3d_<wbr>multi_texturing.php</a> then both of<br>
these behave the same:<br>
<br>
1. ImageTexture { url "my_texture.png" }<br>
<br>
2. MultiTexture { texture ImageTexture { url "my_texture.png" } }<br>
<br>
Both of the above modulate, by default, on all (RGBA) channels. They<br>
are exactly equal for all texture types (RGB or grayscale, with or<br>
without alpha channel). And a texture without alpha is like texture<br>
with alpha = 1, and a grayscale texture is like texture with<br>
red=green=blue.<br>
<br>
You can actually test it with view3dscene and Castle Game Engine already.<br>
<br>
(If one would instead follow the current X3D specification literally, then<br>
1. would sometimes replace, sometimes modulate, depending on<br>
RGB/grayscale format of the texture.<br>
2. would always modulate (regardless if texture is grayscale or RGB),<br>
at least on RGB channels. The spec is ambiguous what to do with alpha<br>
in this case. See the first point of my page<br>
<a href="https://castle-engine.io/x3d_multi_texturing.php#section_problems_solutions" rel="noreferrer" target="_blank">https://castle-engine.io/x3d_<wbr>multi_texturing.php#section_<wbr>problems_solutions</a><br>
for explanations.)<br>
<br>
And if you want to explicitly request some mode, then (after<br>
multi-texturing spec is fixed+extended as I propose on<br>
<a href="https://castle-engine.io/x3d_multi_texturing.php" rel="noreferrer" target="_blank">https://castle-engine.io/x3d_<wbr>multi_texturing.php</a> ) you can write this:<br>
<br>
# replace RGBA<br>
MultiTexture { texture ImageTexture { url "my_texture.png" } mode "REPLACE" }<br>
<br>
# modulate RGB, replace alpha<br>
MultiTexture { texture ImageTexture { url "my_texture.png" } mode<br>
"MODULATE / REPLACE" }<br>
<br>
# replace RGB, modulate alpha<br>
MultiTexture { texture ImageTexture { url "my_texture.png" } mode<br>
"REPLACE / MODULATE" }<br>
<br>
Regards,<br>
Michalis<br>
</blockquote></div><br></div>