[x3d-public] x3d-public Digest, Vol 140, Issue 102

[Andreas Plesch]

x3dom uses vec3 for SFColor, and vec4 for SFColorRGBA.

https://doc.x3dom.org/tutorials/lighting/customShader/index.html

has a list of uniforms which are made available.



> Date: Mon, 30 Nov 2020 10:51:38 +0100
> From: Michalis Kamburelis <michalis.kambi at gmail.com>
> To: John Carlson <yottzumm at gmail.com>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] Mapping SFColor to GLSL - vec3 or vec4?
> Message-ID:
>         <
> CAKzBGZNoZ7abuXBw_QVDeJ_WmKCd2n_U1XcmqS0F7BDBd6Vs8g at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201130/0d2e9e8d/attachment.html>