<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body dir="auto"><div dir="auto">X_ITE does map SFColor to vec3 which is as you meantioned more intuitively. If an author needs a color as vec4 he can define a SFColorRGBA as well. Technically it is also more elegantly to use vec3.</div><div dir="auto"><br></div><div dir="auto">Holger</div><div dir="auto"><br></div><div><br></div><div dir="auto" style="font-size:100%;color:#000000"></div><div style="font-size:100%;color:#000000" dir="auto" align="left"><div>-------- Ursprüngliche Nachricht --------</div><div>Von: Michalis Kamburelis <michalis.kambi@gmail.com> </div><div>Datum: 30.11.20 10:53 (GMT+01:00) </div><div>An: John Carlson <yottzumm@gmail.com> </div><div>Cc: X3D Graphics public mailing list <x3d-public@web3d.org> </div><div>Betreff: Re: [x3d-public] Mapping SFColor to GLSL - vec3 or vec4? </div><div><br></div></div>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>https://castle-engine.io/compositing_shaders.php , 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 <yottzumm@gmail.com> 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 <michalis.kambi@gmail.com> 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 <yottzumm@gmail.com> 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 <michalis.kambi@gmail.com> 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>>>>> https://castle-engine.io/x3d_implementation_shaders.php 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>>>>> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/shaders_glsl.html#Otherfields<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>>>>> x3d-public@web3d.org<br>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org<br><br>_______________________________________________<br>x3d-public mailing list<br>x3d-public@web3d.org<br>http://web3d.org/mailman/listinfo/x3d-public_web3d.org<br></body></html>