[x3d-public] Mapping SFColor to GLSL - vec3 or vec4?

[Michalis Kamburelis]

It is not as simple as "let's all get together and define a standard".
Various browsers do various things at the implementation side, and
that's not going to change (otherwise, X3D would heavily dictate the
implementation, which it rightly doesn't do). This implicates what
GLSL uniforms and attributes are provided. Also even the small
difference of "OpenGL vs OpenGLES vs WebGL" is causing small
incompatibilities in practical GLSL code.

I have a solution to this,
https://castle-engine.io/compositing_shaders.php , which means you
don't depend on predefined uniform names (instead you can "listen" on
specific GLSL points). But only FreeWRL implemented it, and I don't
really dare going into a long process of trying to put this into X3D
standard.

So I don't think Khronos (or anyone else) can magically "make custom
shaders portable across browsers". But, as I wrote above -- shaders
remain so powerful feature, that it's worth it, even if shaders are
not portable. Simply speaking, shaders are for "power-users" that can
decide "my shaders will only work on X, Y browsers, rest of browsers
will see some fallback".

And the gl_ prefix for GLSL variables is a historical thing coming
from now-deprecated OpenGL versions. The browsers add different prefix
because they all pass data in a different way for some things. Hiding
this (e.g. having "gl_ModelViewMatrix" in all browsers) isn't solving
the problem, it would be only pretending to solve it (because it would
only work in simplest situations). If your solution allows to write
shaders in "some" very limited situations (e.g. "it works... unless
you use lights or animation by skinning, which gets widely different
shader input across browsers") then it's just a band-aid, not a "real"
solution that can be applied in larger applications (because in "real"
applications, things do have lighting, skinned animation etc.)

Regards,
Michalis

pon., 30 lis 2020 o 06:07 John Carlson <yottzumm at gmail.com> napisał(a):
>
>
> I think my point is one of “let’s all get together and define a standard.”  But perhaps the shading language is more Khronos’ bailiwick instead of Web3d’s.
>
> I encourage you to use gl_ variables as found in standalone browsers.
>
> John
> On Sun, Nov 29, 2020 at 9:54 PM Michalis Kamburelis <michalis.kambi at gmail.com> wrote:
>>
>> John,
>>
>> This is not a thread about the portability of shader code :) That said...
>>
>> Portability of ComposedShader is indeed a problem. But OTOH being able to write shader code is incredibly powerful, which is why all game engines and rendering libraries, big and small, allow it in one way or another.
>>
>> In CGE we allow shaders in ComposedShader (standard), Effect (extension for compositing effects), ScreenEffect (extension for screen-space post-processing). If X3D didn't have an approach to write shader code in the standard, I would have to invent it anyway, because engine users absolutely expect this capability.
>>
>> Of note is that glTF is also working on it ( KHR_techniques_webgl ). I recall Collada also had some way to define it.
>>
>> Regards,
>> Michalis
>>
>> W dniu pon., 30.11.2020 o 03:39 John Carlson <yottzumm at gmail.com> napisał(a):
>>>
>>> Michalis, I would like the variables taken out of GLSL to be put back into X3D.   It’s totally ridiculous to maintain O(2*N) shaders when only 2 are required with N being number of browser vendors.  It would even be better if a few of the common variables were shared.
>>>
>>> So Shaders are pretty much deprecated in favor of PBR.   If you’ve implemented prismatic PBR, I would be interested...
>>>
>>> John
>>>
>>> On Sun, Nov 29, 2020 at 3:19 PM Michalis Kamburelis <michalis.kambi at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> This is a question to X3D implementors that support GLSL shaders (that
>>>> is, "ComposedShader" node with language="GLSL"). With custom fields in
>>>> ComposedShader mapping to GLSL uniform values. (See
>>>> https://castle-engine.io/x3d_implementation_shaders.php for CGE docs.)
>>>>
>>>> Do you map SFColor to vec3 or vec4 in GLSL?
>>>>
>>>> Similarly, do you map MFColor to vec3[] or vec4[] in GLSL?
>>>>
>>>> The reason why I'm asking:
>>>>
>>>> - The X3D specification 3.3 says to map SFColor / MFColor to vec4 /
>>>> vec4[] in GLSL. See "I.4.2 X3D Field types to GLSL data types",
>>>> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/shaders_glsl.html#Otherfields
>>>> . The X3Dv4 (latest WD2) doesn't change it.
>>>>
>>>> - However, SFColor is an RGB color. That is, it doesn't contain alpha
>>>> value. (We have dedicated SFColorRGBA for a color with alpha
>>>> information.) Same goes for MFColor -- it's a list of RGB colors.
>>>>
>>>> - So it would be much more natural to map SFColor to vec3, and MFColor
>>>> to vec3[]. In case of large MFColor arrays, it would be also more
>>>> optimal, since you pass 3/4 less data to the GPU.
>>>>
>>>> - So far, for a long time, view3dscene / Castle Game Engine
>>>> implemented the X3D spec literally, and we mapped SFColor / MFColor to
>>>> vec4 / vec4[]. But it is really unexpected for authors (costed me
>>>> quite some time recently to figure out "why do I have an error here, I
>>>> send SFColor to vec3, it should work..."). And it is inefficient, if
>>>> you think about large MFColor arrays.
>>>>
>>>> - So I'm curious, what others (X3DOM? FreeWRL? etc.) do. If some /
>>>> most of the actual implementations map SFColor / MFColor -> vec3 /
>>>> vec3[], then maybe we can just fix the specification, to say something
>>>> better?
>>>>
>>>> Regards,
>>>> Michalis
>>>>
>>>> _______________________________________________
>>>> x3d-public mailing list
>>>> x3d-public at web3d.org
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org