[x3d-public] List of X3D problems or missing features, from the point of view of Michalis and Castle Game Engine

[GPU Group]

I'll try and step into the shoes of 'those with power' and see what they
are thinking.
1. does it break old behaviour
It sounds like we would be breaking old behavior.
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.
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;
if you've got a way to do it that doesn't break old, that would be a big
boost.
(But having said that, view3dscene would face broken scenes if you changed
to not break the other 9,000,000 scenes)
if breaking, Is there a scene-upgrader utilitly/ETL?

2. are other browser developers on-side
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.
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.

3. is there a 'model scene' or prototype scene that we can look at the
syntax, and run?
- 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.
Since its a visual effect proposal, maybe a screenshot of what it should
look like when rendered, would clarify the proposal.
For this particular case, how about showing what something like sharkLefty
would look like.
http://x3dgraphics.com/examples/X3dForWebAuthors/KelpForestExhibit/SharkLeftyIndex.html
- it has material, imagetexture, and cpv (that is set false but can be
turned on).
Or something like it where we can see permutations of the old way and
compare to permutations of the new way.

4. timing.
- Is there a major new version in the works
- are browser devlopers opening their IDEs and upgrading test scenes for
other reasons
In this case v4 is in the works, seems like good timing


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.

-Doug

Maybe what I can do to help over in freewrl is get a 2nd implementation
working with some commandline or menu option.
- I have internal #defines. But not triggering based on file version or
node fields.
- I think right now freewrl is set half-way between replace and modulate,
so I need to do something with options anyway
x but will take me a few weeks to get to it and do an .msi


On Mon, Mar 5, 2018 at 3:41 AM, Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:

>  2018-03-05 11:12 GMT+01:00 Michalis Kamburelis <michalis.kambi at gmail.com
> >:
> > If you want to change the behavior of channels (e.g. to "replace"
> > instead of "modulate" on all RGBA channels, or to "replace" only on
> > the alpha channel but modulate on RGB) then use the multi-texturing
> > nodes with a single texture. MultiTexture.mode field was invented
> > exactly to specify such thing, and it should work equally well when
> > you just place a single texture inside MultiTexture. Unfortunately,
> > the MultiTexture specification is ambiguous... but I propose how to
> > fix it, and also extend, on
> > https://castle-engine.io/x3d_multi_texturing.php . (My view3dcene and
> > Castle Game Engine already implement it, if you want to check.)
> >
>
> Maybe some examples will help to convey what I mean in the paragraph above
> :)
>
> If we would apply X3D specification changes that I propose on
> https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-
> textures-treatment-consistent
> *and* on https://castle-engine.io/x3d_multi_texturing.php then both of
> these behave the same:
>
> 1. ImageTexture { url "my_texture.png" }
>
> 2. MultiTexture { texture ImageTexture { url "my_texture.png" } }
>
> Both of the above modulate, by default, on all (RGBA) channels. They
> are exactly equal for all texture types (RGB or grayscale, with or
> without alpha channel). And a texture without alpha is like texture
> with alpha = 1, and a grayscale texture is like texture with
> red=green=blue.
>
> You can actually test it with view3dscene and Castle Game Engine already.
>
> (If one would instead follow the current X3D specification literally, then
> 1. would sometimes replace, sometimes modulate, depending on
> RGB/grayscale format of the texture.
> 2. would always modulate (regardless if texture is grayscale or RGB),
> at least on RGB channels. The spec is ambiguous what to do with alpha
> in this case. See the first point of my page
> https://castle-engine.io/x3d_multi_texturing.php#section_
> problems_solutions
> for explanations.)
>
> And if you want to explicitly request some mode, then (after
> multi-texturing spec is fixed+extended as I propose on
> https://castle-engine.io/x3d_multi_texturing.php ) you can write this:
>
> # replace RGBA
> MultiTexture { texture ImageTexture { url "my_texture.png" } mode
> "REPLACE" }
>
> # modulate RGB, replace alpha
> MultiTexture { texture ImageTexture { url "my_texture.png" } mode
> "MODULATE / REPLACE" }
>
> # replace RGB, modulate alpha
> MultiTexture { texture ImageTexture { url "my_texture.png" } mode
> "REPLACE / MODULATE" }
>
> Regards,
> Michalis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180305/1b3a60ba/attachment-0001.html>