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

[Michalis Kamburelis]

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/ea5bdfe9/attachment.html>