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

[GPU Group]

 > Only 1 browser out of 6 manages to be 100% conforming to the current
specification...
CONFIRMED I ran your test, with various browsers, and saw no consistency.
On behalf of freewrl project, I support the change as a function of web3d
file version number.
ie if(version >= 4) full blend else v3.3-- specs.
-Doug

On Mon, Mar 5, 2018 at 2:19 PM, Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:

> 2018-03-05 16:51 GMT+01:00 GPU Group <gpugroup at gmail.com>:
> > 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.
>
> First of all, note that you are focusing on one issue among a couple
> (of mostly independent ones) on my wiki. I just want to clarify that,
> for anyone reading :) We are discussing this aspect:
> https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-
> textures-treatment-consistent
> .
>
> As for test scenes:
>
> The testcase is linked on
> https://castle-engine.io/x3d_multi_texturing.php , with test results
> on various X3D browsers. It's named "9.
> material_color_mixed_with_texture_color:". The X3D in classic encoding
> is here:
>
> https://raw.githubusercontent.com/castle-engine/demo-models/
> master/multi_texturing/material_color_mixed_with_texture_color.x3dv
>
> The X3D in XML encoding is here:
>
> https://raw.githubusercontent.com/castle-engine/demo-models/
> master/multi_texturing/material_color_mixed_with_texture_color.x3d
>
> As for backward compatibility:
>
> 1. I initially made my proposal a few years ago, partially because the
> existing browsers were already *very* incompatible in this case.
> ("Whether to replace, or multiply, texture color.") And I just tested
> today, on existing latest X3D browsers, and the results are different,
> better than a few years ago... and still incompatible. Only 1 browser
> out of 6 manages to be 100% conforming to the current specification...
>
>     (And I'm not counting here my own view3dscene, that does something
> different than the current specification deliberately.)
>
>     See the details on
> https://castle-engine.io/x3d_multi_texturing.php , the table cell
> titled "9. material_color_mixed_with_texture_color".
>
>     So the 1st goal of my proposition was to make this behavior more
> consistent in future X3D version, across all browsers.
>
>     Bottom line: The compatibility is already poor, when the existing
> implementations (mis)interpret the current specification in various
> (different) ways.
>
> 2. Note that view3dscene and Castle Game Engine work like this (that
> is: always multiply, even for RGB textures, contradicting the X3D
> specification) from day one. And there was zero bugreports about this.
> Probably because some X3D browsers already work like this, or because
> all other graphic software (outside of X3D) already works like this
> (Unity3d materials, Blender materials... they all multiply, always).
>
>     So, let us not over-exaggerate compatibility breakage. My proposal
> tries to make things non-surprising for authors, and consistent across
> browsers. That's what spurred my initial need to fix this.
>
> 3. The 2nd goal of my proposal is to increase interoperability with
> other software (outside X3D). Everyone else is just multiplying
> colors, not differentiating between RGB and grayscale textures. I
> mentioned already default Unity3d materials and Blender materials as
> example. I worked with various 3D authoring tools, and as far as I
> know --- no software, and no other 3D format, works like X3D
> specification dictates (replace RGB textures, multiply grayscale
> textures), at least by default. My proposal would make default X3D
> material behavior more consistent with others.
>
>     E.g. right now Blender exporter is not strictly correct, if we
> consider that Blender materials always multiply texture*color, while
> the exported X3D scene will not always multiply (if current X3D
> specification is implemented literally).
>
> Bottom line: I very much share your concern about
> backward-compatibility. But in this case, we do not have cross-browser
> compatibility anyway, right now. (And I think this lack of
> compatibility is because the specification behavior is both
> complicated for implementors, and unnecessarily limited for users.)
>
> As for X3D version: indeed I propose to change it with a major version X3D
> 4.0.
>
> Regards,
> Michalis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180305/d20e12fd/attachment-0001.html>