Write your own Einstein@home screensaver

Basic Shaders for Dummies

It looks like I'll be able to get away with bland & basic shaders and pipeline configuration. In fact I will/am abstracting all the key GLSL constructs in a C++/OOP framework. I reckon I'll go up to a 'PipelineConfig' class which will comprise all shaders and associated data structures/buffers for a given display task eg. render the Earth, render the constellations etc. The key point is to regularise all the annoying GL/GLSL interfacing specific workload within and allow a higher level of thinking.

[ For that matter I think the framework can/will generalise well beyond our E@H screensaver focus as applied here ie. a multi-target cross-compile build system for OpenGL ES. What are the possible applications of that ? :-) :-) ]

GLSL has a superficial appearance to C/C++/Java, but don't be fooled! I think it has that look & feel to make us comfortable, but the paradigm is truly different.

- identifiers/symbols are case-sensitive, composed of one or more alphanumeric characters plus the underscore ( '_' ). The first character must not be a numeric digit nor the underscore. Consecutive underscores ( '__' ) are disallowed anywhere within a symbol, as these are GLSL reserved. As are those beginning 'gl_'.

- whitespace is free-form, thus language parsing is indifferent to whether the symbols are separated by a space, multiple spaces, tab character, CR and/or LF, combinations thereof. But be smart and use the given freedom to make it easy to understand at a glance.

- shader code is merely a single ASCIIZ terminated string or an array of same ( eg. one string per 'line' ). To be exact a single string is an array of strings with only one/first element.

- statements end with a semicolon.

- flow-control/iteration/test is per C except no 'goto' ie. functions with expected semantics, if-else, switch-case​, for​, while​, do-while, break​, continue​ and return​.

- recursion is illegal.

- comments are :

[pre]// Single line like this, or

/*
Multi-line beasts.
For as many as you like,
exhaustion limited.
*/[/pre]
- the first non-whitespace line ought be like so :

[pre]#version 330 core[/pre]
.... declaring the GLSL version and profile. If you don't you'll get 110/1.1 core, probably not what you wanted. At GLSL compilation time - which is at run time for your executable - one will be held to that declaration. There is a correspondence b/w OpenGL and GLSL versions :

[pre]GL GLSL
2.0 1.10
2.1 1.20
3.0 1.30
3.1 1.40
3.2 1.50[/pre]
where for OpenGL 3.3 and above, the corresponding GLSL version matches the OpenGL version eg. GL 4.1 uses GLSL 4.10, which appears in the shader as 410.

- the executable part is within this construct :

[pre]void main() {
// Doing stuff here.
}[/pre]
... where 'void main()' is just syntactic sugar to resemble C/C++, as there is never a return type, no parameters are ever passed as an argument list, and the name is 'main' for all shaders. So it's merely a delimiter of the code statements with familiar appearance.

- as opposed to data declarations. You can have both before the code block or within. For those declared prior to the 'main' block eg.

[pre]#version 330 core

in vec4 vPosition;
in vec4 vColor;

out vec4 color;

uniform mat4 ModelViewProjectionMatrix;

void main() {
color = vColor;
gl_Position = ModelViewProjectionMatrix * vPosition;
}[/pre]
these correlate to values being fed by the required Vertex Array Object - the 'in' variables - or set/updated on occasion by the application - the 'uniform' variables. The 'out' variable is passed to ( or is an alias for ) a variable of the same name which is an 'in' further along. Here we are evidently simply passing a color value through a vertex shader to be actually considered by a fragment shader*. Hence the 'in' and 'out' variables have per-vertex values, whereas the 'uniform' has a given value for any vertex until updated. 'gl_Position' is a reserved name having the special meaning to the pipeline as that ( transformed ) vertex position in clip space ( as previously discussed ). Inconsistently, a fragment shader's output is an 'out vec3' or 'out vec4' of any name you like, the vector length typically depending on the presence/otherwise of an alpha channel.

[ 'gl_Position' is thus a special notation for a variable with 'out' functionality. One particular reason for that ( I think ) is that vertex position attributes must be rounded up into groups on a per-primitive basis later on. To properly clip for instance one must know what geometric object type is being worked upon. ]

- obviously we are doing a mat4 * vec4 -> vec4, assumed float numeric type of the array/vector elements. This being single precision IEEE-754 specification, or very close to if GLSL version is 110 or 120 ( possible hardware dependence ).

More later. ;-)

Cheers, Mike.

* To be precise the fragment shader deals with fragments ie. what the rasteriser has determined to be pixel candidates. The pipeline between vertex shader and rasteriser has a number of other transforms eg. clipping, perspective division and viewport. Thus there are also issues of magnification ( single fragment to many pixels ) and minification ( many fragments to a single pixel ) ....

( edit ) I've done "ready reckoner", "in a nutshell" and "for dummies" so far. I'll have to follow modern publishing trends and follow up with zingers like "Schrodinger's Shader", "Einstein's Screensaver", "Feynman Fragmented", "Fermi and the Pipeline" or "Dirac Meets the Transform". Fortunately cognitive dissonance will be quite unimportant. :-) :-)