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

Michalis Kamburelis michalis.kambi at gmail.com
Tue Dec 1 05:58:30 PST 2020


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



More information about the x3d-public mailing list