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

[GPU Group]

One more thing the proposer(s) can do to help decision makers:
- re-write the specs, showing editing: strikeout on old and underlined on
new.

On Mon, Mar 5, 2018 at 3:23 PM, GPU Group <gpugroup at gmail.com> wrote:

> > 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/20180306/6dc4a583/attachment-0001.html>