[x3d-public] Collect Shader variable documentation links into a single page

[doug sanden]

M,
Thanks - Q. is this the page I should be looking at for how to implement plugs?
http://castle-engine.sourceforge.net/compositing_shaders_doc/html/chapter.implementation.html
-D
________________________________________
From: Michalis Kamburelis <michalis.kambi at gmail.com>
Sent: January 12, 2016 2:35 PM
To: doug sanden; X3D Graphics public mailing list
Subject: Re: [x3d-public] Collect Shader variable documentation links into a single page

Our compositing shaders work on OpenGLES 2 without any problems :), we
use them in our mobile projects. For example
https://play.google.com/store/apps/details?id=net.sourceforge.castleengine.darkestbeforedawn
, free Android 3D game, it uses Castle Game Engine and X3D inside, and
the lighting tricks are done with compositing shaders extensions.

They don't require the OpenGL "Shader Subroutines", instead they rely on
simple text processing of GLSL code on the CPU side. In
http://castle-engine.sourceforge.net/compositing_shaders.php we briefly
outline this simplest implementation. This approach can in fact work
with other shading languages, like Cg or HLSL, as no GPU specific
support is required (although the exact effect code is still done in a
specific shading language).

Michalis

doug sanden wrote:
> Michalis,
> very interesting point of differentiation for castle game engine, very advanced.
> -Doug
> more..
> I think the plugs are too advanced for GLES2 if you need gl functions listed on this page:
> https://www.opengl.org/wiki/Shader_Subroutine
> - I get these functions with desktop opengl 4.3 but not angleproject
> For those working more on the lowest common denominator GLES2 or near-equivalent desktop opengl 2.1 -including angleproject which firefox and chrome use to implement webgl over directx on windows via translation- we can't do anything quite so fancy. Pity. And we can't rely on gl_ModelViewMatrix - but one idea is to use this name, and if it's supported by the opengl version then don't inject a uniform, else do. But: more chance of mix-up detecting opengl versions, and then the shader won't compile if both opengl and the engine/browser inject it.
>
>
>
> ________________________________________
> From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Michalis Kamburelis <michalis.kambi at gmail.com>
> Sent: January 12, 2016 11:46 AM
> To: John Carlson; Don Brutzman; X3D Graphics public mailing list
> Subject: Re: [x3d-public] Collect Shader variable documentation links into a single page
>
> John Carlson wrote:
>> On Jan 11, 2016, at 5:47 PM, John Carlson <yottzumm at gmail.com
>> <mailto:yottzumm at gmail.com>> wrote:
>>
>> Don, can we collect Shader variable documentation links into a single
>> page on www.web3d.org <http://www.web3d.org/>  This will be the first
>> step at finding commonality.
>>
>> X3DOM:  http://doc.x3dom.org/tutorials/lighting/customShader/index.html
>> FreeWRL: http://freewrl.sourceforge.net/FreeX3D/Component_ProgrammableShaders.html
>> Cobweb:  http://titania.create3000.de/cobweb/custom-shaders/
>> BS
>> Contact: http://www.bitmanagement.com/developer/contact/examples/shader/shader.html
>> Standard OpenGL: ?
>>
>
> Castle Game Engine documentation about shaders is on
> http://castle-engine.sourceforge.net/x3d_implementation_shaders.php .
> However, we did not introduce any built-in magic variables in GLSL,
> thinking that it would be just a dirty hack. Instead:
>
> 1. The most preferred way to write shaders is to use our "Compositing
> Shaders" extensions, documente on
> http://castle-engine.sourceforge.net/compositing_shaders.php extensions
> , to create shader effects.
>
>   This avoids the need to have any "magic" uniforms (defined by the
> engine and used by X3D authors). Instead, you simply define GLSL
> functions that get all they need through their parameters.
>
> 2. To pass additional information to your shaders, you use X3D
> specification sanctioned approach: ROUTE the necessary information from
> the nodes to your shaders. This is documented on
> http://castle-engine.sourceforge.net/x3d_implementation_shaders.php and
> in many examples.
>
>   This is the best way to pass information either to standard shaders
> (X3D ComposedShader node) or to our compositing shaders (X3D Effect node).
>
> 2.1. In particular, to get camera matrix, ROUTE the appropriate
> Viewpoint events:
>
>   SFMatrix4f [out]         cameraMatrix
>   SFMatrix4f [out]         cameraInverseMatrix
>   SFMatrix3f [out]         cameraRotationMatrix
>   SFMatrix3f [out]         cameraRotationInverseMatrix
>
> Documented on
> http://castle-engine.sourceforge.net/x3d_implementation_navigation_extensions.php#section_ext_viewpoint_camera_matrix
>
> 3. Finally: as a last resort, you can also use GLSL build-in variables,
> like gl_Vertex or gl_ModelViewMatrix. The full list is in GLSL 1.20
> specification. But this is only available on desktops (OpenGL, not
> OpenGLES) and is very discouraged (newer GLSL language versions removed it).
>
> Regards,
> Michalis
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>