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

Sat Dec 5 13:52:52 PST 2020

Thank you Don!

Checked, all good, issue fixed :)

Regards,
Michalis

sob., 5 gru 2020 o 22:46 Don Brutzman <brutzman at nps.edu> napisał(a):
>
> 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