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

[Michalis Kamburelis]

I was writing this mail on a phone and for some reason I see it decided to
format the last paragraph with invisible text color, either white on white
or dark on dark, depending on theme :) Here's the last paragraph of my last
mail again, hopefully this time readable :

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 04:54 Michalis Kamburelis <
michalis.kambi at gmail.com> napisał(a):

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