<div dir="auto">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 :</div><div dir="auto"><br></div><div dir="auto">Of note is that glTF is also working on it ( KHR_techniques_webgl ). I recall Collada also had some way to define it.<br></div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Michalis</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">W dniu pon., 30.11.2020 o 04:54 Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">John,</div><div dir="auto"><br></div><div dir="auto">This is not a thread about the portability of shader code :) That said...</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255);color:rgb(255,255,255)" dir="auto"><span>Of note is that glTF is also working on it ( </span>KHR_techniques_webgl ). I recall Collada also had some way to define it.</div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto"><br></div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto">Regards,</div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto">Michalis</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">W dniu pon., 30.11.2020 o 03:39 John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">So Shaders are pretty much deprecated in favor of PBR.   If you’ve implemented prismatic PBR, I would be interested...</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"></div></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 29, 2020 at 3:19 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br></div></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"></blockquote></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Hi,<br>
<br>
This is a question to X3D implementors that support GLSL shaders (that<br>
is, "ComposedShader" node with language="GLSL"). With custom fields in<br>
ComposedShader mapping to GLSL uniform values. (See<br>
<a href="https://castle-engine.io/x3d_implementation_shaders.php" rel="noreferrer" target="_blank">https://castle-engine.io/x3d_implementation_shaders.php</a> for CGE docs.)<br>
<br>
Do you map SFColor to vec3 or vec4 in GLSL?<br>
<br>
Similarly, do you map MFColor to vec3[] or vec4[] in GLSL?<br>
<br>
The reason why I'm asking:<br>
<br>
- The X3D specification 3.3 says to map SFColor / MFColor to vec4 /<br>
vec4[] in GLSL. See "I.4.2 X3D Field types to GLSL data types",<br>
<a href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/shaders_glsl.html#Otherfields" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/shaders_glsl.html#Otherfields</a><br>
. The X3Dv4 (latest WD2) doesn't change it.<br>
<br>
- However, SFColor is an RGB color. That is, it doesn't contain alpha<br>
value. (We have dedicated SFColorRGBA for a color with alpha<br>
information.) Same goes for MFColor -- it's a list of RGB colors.<br>
<br>
- So it would be much more natural to map SFColor to vec3, and MFColor<br>
to vec3[]. In case of large MFColor arrays, it would be also more<br>
optimal, since you pass 3/4 less data to the GPU.<br>
<br>
- So far, for a long time, view3dscene / Castle Game Engine<br>
implemented the X3D spec literally, and we mapped SFColor / MFColor to<br>
vec4 / vec4[]. But it is really unexpected for authors (costed me<br>
quite some time recently to figure out "why do I have an error here, I<br>
send SFColor to vec3, it should work..."). And it is inefficient, if<br>
you think about large MFColor arrays.<br>
<br>
- So I'm curious, what others (X3DOM? FreeWRL? etc.) do. If some /<br>
most of the actual implementations map SFColor / MFColor -> vec3 /<br>
vec3[], then maybe we can just fix the specification, to say something<br>
better?<br>
<br>
Regards,<br>
Michalis<br>
<br></blockquote></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>