[x3d-public] Basic Shaders

[Andreas Plesch]

It looks like the simpleShader scene was just updated to use light
direction rather than light location:

http://www.web3d.org/x3d/content/examples/Basic/Shaders/SimpleShaderIndex.html
(The CDATA does not show but should in the xml:
http://www.web3d.org/x3d/content/examples/Basic/Shaders/SimpleShaderCanonical.xml
)

So I updated the x3dom port accordingly:
https://rawgit.com/andreasplesch/x3dom/inlineShader/test/regression-suite/test/cases/composedShader/inlineShader.xhtml

It is more sensible to use direction since the headlight is a directional light.

In x3dom it was necessary to invert the light direction, and the
center ring is broader.

BTW: x_cite produces this helpful warning on
http://www.web3d.org/x3d/content/examples/Basic/Shaders/SimpleShaderIndex.html:

x_ite.min.js:15 ComposedShader Cobweb Using uniform location name
»x3d_LightDirection[0]« is depreciated. See
http://create3000.de/x_ite/custom-shaders/.

One is supposed to use vec3(x3d_LightSource[0].direction) where
uniform x3d_LightSourceParameters x3d_LightSource[8] .
as in:
vec3 light_dir = x3d_LightSource[0].direction;
intensity = dot (-light_dir, n);
Hm, I just found that with the new uniform, it is also necessary to
invert the direction in x_ite.

-Andreas

On Tue, May 22, 2018 at 12:57 PM, Andreas Plesch
<andreasplesch at gmail.com> wrote:
>> Date: Tue, 22 May 2018 00:52:54 -0400
>> From: John Carlson <yottzumm at gmail.com>
>> To: Don Brutzman <brutzman at nps.edu>,  X3D Graphics public mailing list
>>         <x3d-public at web3d.org>
>> Subject: [x3d-public] CDATA sections don't show up on this X3D
>>         Resources Example, Basic Shaders, that  I can see in the decorated X3D
>> Message-ID: <5b03a226.1c69fb81.c965e.d3da at mx.google.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I haven?t tried copy/paste.
>>
>> http://www.web3d.org/x3d/content/examples/Basic/Shaders/SimpleShaderIndex.html
>>
>> This is on the web page itself.
>>
>> Also X_ITE is drastically different from something like BS Contact for example.
>>
>> We need more ports. FreeWRL? X3DOM (maybe put a switch in for the Proto?).
>
> Here is John's port to x3dom:
> https://rawgit.com/andreasplesch/x3dom/inlineShader/test/regression-suite/test/cases/composedShader/inlineShader.xhtml
> . It is a literal port and it is unclear if it results in the expected
> rendering.
>
> I believe the main difference between browsers is in the naming of the
> uniforms supplied to the shader code. I think there was a discussion
> on the list about these naming conventions.
>
> Another source of incompatibility in shaders is the choice of shading
> language. Even within the glsl language, probably the dominant
> language, there are different versions.
>
> A large step towards compatibility would therefore be requiring the
> restricted subset of glsl GLSL ES v3 (for composed custom shaders) as
> the single glsl version:
>
> https://www.khronos.org/registry/OpenGL/specs/es/3.0/GLSL_ES_Specification_3.00.pdf
>
> This had the additional benefit that shaders would be largely
> compatible with webgl2.
>
> Another potential source of incompatibility in the example is in the
> definition of what data uniforms should supply, independent from the
> naming. It looks like some browsers may supply the direction and
> location of lights in object space, others in eye space (already
> transformed by the view matrix). Eye space seems to be what gl
> traditionally supplies for lights.
>
> -Andreas



-- 
Andreas Plesch
Waltham, MA 02453