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

[Michalis Kamburelis]

 2018-03-04 21:23 GMT+01:00 GPU Group <gpugroup at gmail.com>:
> OK. Any hypotheses for the remaining issues holdup / slow progress?

I don't know.

While *some* of the issues on
https://github.com/michaliskambi/x3d-tests/wiki are not trivial,
*some* of them seem trivial and/or they were already discussed and the
consensus was reached (e.g.
https://github.com/michaliskambi/x3d-tests/wiki/Clarify-the-usage-of-quotes-and-backslashes-for-MFString-and-SFString-in-XML-encoding
). I guess just lack of time of people that have the power to actually
modify the specification.

> Example: For blending, what would the x3d syntax look like if I want no
> blending? Or 50/50?
> One problem: how to make the old fashioned no-blend the default. Lets give
> that design principle a name. How about New Defaults Preserve Old Ways.
> How about
> Material {
> SFFloat blendWithTexture 0 [0-1]
> }
> with 1 meaning "use material, except for texture transparency, if/when
> texture loads." and 0 meaning texture over-rides material 100% - the old
> way.
>
> Or do you have the syntax and semantics worked out already? If so what does
> it look like? And does it meet all design principles stated by web3d.org on
> their design principles page?

Note that you're talking here about something outside of my proposal
on https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent
. The point of my page is to unify the treatment of RGB and grayscale
textures. What to do with alpha channel -- is another question,
independent, that I did not address there, to keep things simple.

That said, since we talk about it: I would say that it
should modulate by default. That is, multiply alpha channel of the texture with
Material.alpha (which is of course "1-Material.transparency"). This
follows the idea that "a texture without alpha channel should behave
the same as a texture with alpha channel existing, but always
equal 1.0". In total, it makes a simple, consistent rule:

    The complete texture color (red, green, blue, alpha) is multiplied
by the Material color, always.
    If a texture is grayscale, then it behaves like red = green = blue
on all pixels.
    If a texture does not have alpha channel,then it behaves like
alpha = 1 on all pixels.

I don't think we need any additional fields, like Material
blendWithTexture. The point is to make a behavior that is unsurprising
and obvious to X3D authors, so it should just be the default.

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.)

Regards,
Michalis