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

Sat Dec 5 13:46:22 PST 2020

Thanks for flagging this as a specification error, that small detail had eluded me during all the prior elaboration...

Now in our issue tracker, for accountability:

* Mantis 1328: corresponding color types for GLSL shaders
   https://www.web3d.org/member-only/mantis/view.php?id=1328

Seems totally straightforward.  Applied, closed issue.  Confirmation welcome.

* X3D4 Annex I (normative) OpenGL shading language (GLSL) binding
   Table I.3 — Mapping of X3D field types to GLSL data types
   https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/shaders_glsl.html#t-X3DFieldTypeToGLSL

Also sorted some row entries for consistency, SF before MF.

Thanks for this excellent due diligence.

On 12/4/2020 1:03 PM, Michalis Kamburelis wrote:
> 
> 
> Bump :) Don, do you think it's too late to make this change in X3Dv4,
> or can we make it? The proposed change in this thread would make the
> specification in annex "I" actually consistent with what at least 3
> implementations do (X3DOM, X_ITE, CGE).
> 
> Regards,
> Michalis
> 
> wt., 1 gru 2020 o 14:58 Michalis Kamburelis <michalis.kambi at gmail.com>
> napisał(a):
> 
>>
>> Thank you Holger and Andreas!
>>
>> View3dscene / CGE now maps SFColor to vec3 too.
>>
>> Don, this means we want to fix "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
>> , to say that
>>
>> - SFColor maps to vec3
>> - MFColor maps to vec3[]
>> - SFColorRGBA maps to vec4
>> - MFColorRGBA maps to vec4[]
>>
>> Currently, spec says that SFColor / MFColor map to vec4 (wrong) and is
>> silent about SFColorRGBA / MFColorRGBA. I don't think there were any
>> changes during X3Dv4 development cycle to this annex.
>>
>> This change will reflect what the browsers *already do* (X3DOM, X_ITE,
>> view3dscene/CGE) and also what is more natural and efficient. SFColor
>> doesn't have alpha, so it should be vec3, not vec4.
>>
>> Regards,
>> Michalis
>>
>>
>> pon., 30 lis 2020 o 13:22 Holger Seelig <holger.seelig at yahoo.de> napisał(a):
>>>
>>> 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.
>>>
>>> Holger
>>>
>>>
>>> -------- Ursprüngliche Nachricht --------
>>> Von: Michalis Kamburelis <michalis.kambi at gmail.com>
>>> Datum: 30.11.20 10:53 (GMT+01:00)
>>> An: John Carlson <yottzumm at gmail.com>
>>> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
>>> Betreff: Re: [x3d-public] Mapping SFColor to GLSL - vec3 or vec4?
>>>
>>> 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
>>>
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman