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

Fri Dec 4 13:03:10 PST 2020

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