<div dir="ltr"><div class="gmail_quote"><div>x3dom uses vec3 for SFColor, and vec4 for SFColorRGBA.</div><div><br></div><div><a href="https://doc.x3dom.org/tutorials/lighting/customShader/index.html">https://doc.x3dom.org/tutorials/lighting/customShader/index.html</a><br></div><div><br></div><div>has a list of uniforms which are made available.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Date: Mon, 30 Nov 2020 10:51:38 +0100<br>
From: Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>><br>
To: John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>><br>
Cc: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
Subject: Re: [x3d-public] Mapping SFColor to GLSL - vec3 or vec4?<br>
Message-ID:<br>
        <<a href="mailto:CAKzBGZNoZ7abuXBw_QVDeJ_WmKCd2n_U1XcmqS0F7BDBd6Vs8g@mail.gmail.com" target="_blank">CAKzBGZNoZ7abuXBw_QVDeJ_WmKCd2n_U1XcmqS0F7BDBd6Vs8g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
It is not as simple as "let's all get together and define a standard".<br>
Various browsers do various things at the implementation side, and<br>
that's not going to change (otherwise, X3D would heavily dictate the<br>
implementation, which it rightly doesn't do). This implicates what<br>
GLSL uniforms and attributes are provided. Also even the small<br>
difference of "OpenGL vs OpenGLES vs WebGL" is causing small<br>
incompatibilities in practical GLSL code.<br>
<br>
I have a solution to this,<br>
<a href="https://castle-engine.io/compositing_shaders.php" rel="noreferrer" target="_blank">https://castle-engine.io/compositing_shaders.php</a> , which means you<br>
don't depend on predefined uniform names (instead you can "listen" on<br>
specific GLSL points). But only FreeWRL implemented it, and I don't<br>
really dare going into a long process of trying to put this into X3D<br>
standard.<br>
<br>
So I don't think Khronos (or anyone else) can magically "make custom<br>
shaders portable across browsers". But, as I wrote above -- shaders<br>
remain so powerful feature, that it's worth it, even if shaders are<br>
not portable. Simply speaking, shaders are for "power-users" that can<br>
decide "my shaders will only work on X, Y browsers, rest of browsers<br>
will see some fallback".<br>
<br>
And the gl_ prefix for GLSL variables is a historical thing coming<br>
from now-deprecated OpenGL versions. The browsers add different prefix<br>
because they all pass data in a different way for some things. Hiding<br>
this (e.g. having "gl_ModelViewMatrix" in all browsers) isn't solving<br>
the problem, it would be only pretending to solve it (because it would<br>
only work in simplest situations). If your solution allows to write<br>
shaders in "some" very limited situations (e.g. "it works... unless<br>
you use lights or animation by skinning, which gets widely different<br>
shader input across browsers") then it's just a band-aid, not a "real"<br>
solution that can be applied in larger applications (because in "real"<br>
applications, things do have lighting, skinned animation etc.)<br>
<br>
Regards,<br>
Michalis<br>
<br>
pon., 30 lis 2020 o 06:07 John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> napisa?(a):<br>
><br>
><br>
> 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.<br>
><br>
> I encourage you to use gl_ variables as found in standalone browsers.<br>
><br>
> John<br>
> On Sun, Nov 29, 2020 at 9:54 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br>
>><br>
>> John,<br>
>><br>
>> This is not a thread about the portability of shader code :) That said...<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> Of note is that glTF is also working on it ( KHR_techniques_webgl ). I recall Collada also had some way to define it.<br>
>><br>
>> Regards,<br>
>> Michalis<br>
>><br>
>> W dniu pon., 30.11.2020 o 03:39 John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> napisa?(a):<br>
>>><br>
>>> 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.<br>
>>><br>
>>> So Shaders are pretty much deprecated in favor of PBR.   If you?ve implemented prismatic PBR, I would be interested...<br>
>>><br>
>>> John<br>
>>><br>
>>> On Sun, Nov 29, 2020 at 3:19 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> This is a question to X3D implementors that support GLSL shaders (that<br>
>>>> is, "ComposedShader" node with language="GLSL"). With custom fields in<br>
>>>> ComposedShader mapping to GLSL uniform values. (See<br>
>>>> <a href="https://castle-engine.io/x3d_implementation_shaders.php" rel="noreferrer" target="_blank">https://castle-engine.io/x3d_implementation_shaders.php</a> for CGE docs.)<br>
>>>><br>
>>>> Do you map SFColor to vec3 or vec4 in GLSL?<br>
>>>><br>
>>>> Similarly, do you map MFColor to vec3[] or vec4[] in GLSL?<br>
>>>><br>
>>>> The reason why I'm asking:<br>
>>>><br>
>>>> - The X3D specification 3.3 says to map SFColor / MFColor to vec4 /<br>
>>>> vec4[] in GLSL. See "I.4.2 X3D Field types to GLSL data types",<br>
>>>> <a href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/shaders_glsl.html#Otherfields" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/shaders_glsl.html#Otherfields</a><br>
>>>> . The X3Dv4 (latest WD2) doesn't change it.<br>
>>>><br>
>>>> - However, SFColor is an RGB color. That is, it doesn't contain alpha<br>
>>>> value. (We have dedicated SFColorRGBA for a color with alpha<br>
>>>> information.) Same goes for MFColor -- it's a list of RGB colors.<br>
>>>><br>
>>>> - So it would be much more natural to map SFColor to vec3, and MFColor<br>
>>>> to vec3[]. In case of large MFColor arrays, it would be also more<br>
>>>> optimal, since you pass 3/4 less data to the GPU.<br>
>>>><br>
>>>> - So far, for a long time, view3dscene / Castle Game Engine<br>
>>>> implemented the X3D spec literally, and we mapped SFColor / MFColor to<br>
>>>> vec4 / vec4[]. But it is really unexpected for authors (costed me<br>
>>>> quite some time recently to figure out "why do I have an error here, I<br>
>>>> send SFColor to vec3, it should work..."). And it is inefficient, if<br>
>>>> you think about large MFColor arrays.<br>
>>>><br>
>>>> - So I'm curious, what others (X3DOM? FreeWRL? etc.) do. If some /<br>
>>>> most of the actual implementations map SFColor / MFColor -> vec3 /<br>
>>>> vec3[], then maybe we can just fix the specification, to say something<br>
>>>> better?<br>
>>>><br>
>>>> Regards,<br>
>>>> Michalis<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> x3d-public mailing list<br>
>>>> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
>>>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br><br></blockquote></div></div>