Created on 03.10.2005 - 23:09

ptikobj

How is this related to OpenGL2, shaders 'n stuff?
Not at all.

So lets start with the topic.
I wonder if anyone could explain the technical background behind that shader-thing from a non-mathematical point of view.
Just imagine I'd be some curious child and you had to explain how such a shader works, how this influences the final picture, the possibilities and some hardware background (pixel pipeline etc).

That way I guess I still won't get it, but maybe someone else who's interested.
^^

Thx in advance.

[Dieser Beitrag wurde am 03.10.2005 - 23:10 von Z aktualisiert]

Created on 04.10.2005 - 00:59

If you want to write shaders it's good to know something about shader variables. (GLSL)

The uniform variables link the "main" program with the shader and are used to influence the processings. (like size of buffer, buffers, offsets,...)

The varying variables use as a link between the vertex and the pixel shader programs. You can calculate some things in the vertex shader, for example and pass it to the fragment shader.

There are also some "built-in" variables, constant variables and atributes in the vertex and pixel shader which you can read and use or write into.
(like gl_Normal, gl_FragColor, gl_MaxFragmentTextureUnitsGL2...)


Every implemented shader unit has it's own logical math unit(s). It can be a vector or(and) a scalar unit. The difference is that a vector unit can do more work in a single turn, like add two vectors with four components. Why vector units? Because colors can be described as vectors, not to mention the spatial coordinates.

What the OGL2 shaders are about is to change the color values in the OGL2Texture (mostly) . Something goes in and something else comes out. Without shades you could do very little (but very fast).

You can use some functions and other statements like the if-statement. Some are faster as other. What really matters in the end is which instructions are simple and which are complex(GLSL). Usualy s simple linear shader with manny simple operations works faster as a shader with complex statements.
But is is not a rule and and may also depend from the compiler, gfx card class (SM 2.0, SM 3.0...)


Further on you must access the information from the texture sampler. You do that with texture lookups which can be only done in fragment shader (most adapters). Then you look at the texels in the environment of the current coordinate and usualy use this informations for the calculation of the gl_FragColor. The "strength of presence" of a color sample is determined with weights which can be offset dependent (gaussian blur), even (box filter) or depend on the difference in the color value (SaL, C2D, SharpSmoother...).

The fragment color can also depend on current coordinate, like in the OGL2Texture lookup shader or pixelate/scanlines shaders.

Shaders are "smaller" programms and have their limiatations with their roots in the architecture of the gfx adapters. With older Dx 9.0 Ati's you cannot write a fragment program larger than 96 instructions, there is no dynamic branching, no (normal, fast)accessing of arrays with a variable...

[Dieser Beitrag wurde am 06.10.2005 - 20:32 von guest aktualisiert]

Created on 04.10.2005 - 11:12

Programmable "shaders" are been born in order to replace gfx (opengl or directx) fixed functionalities like lightening, blending, filtering, etc.
A fixed functionality is, for example, for opengl,
GL_LINEAR.
Ours shaders try to modify/replace this fixed functionality.
Bye