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

[Michalis Kamburelis]

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