GLSL learning need Help

[font="Lucida Console"]Hello i have been working on shaders for a little while now reading the orange book but its just way to technical and i really need things simplified to grasp the concepts that's how i learn in general by interpretating technical and turning it into simplified in my head but this GLSL coding stuff is something else ,i even rit notes trying to understand it and coded alittle from it but wow.

Anyways i was hoping someone would be able to give me a simplified version or basic idea of how shaders work or could send me to a place where it is simplified and to learn it

Is it wrong to not like too much technicality's?

I have looked around on the net namingly the clockworkers,lighthouse,gl site, all sorts and the tutorials arnt working especially the clockworkers one i'm not shore about the other few because i was only looking on how to colorkey.

This is the closes i have found to helping me but it dont work it discards everything rather then select color i asked and my texture has red color on the background ,that color is red like in the example:

http://www.opengl.or...ers/discard.php

thanks in advance[/font]

Technicality is just part of game programming, I'm afraid. Admittedly, though, shader programming can be a little complex to wrap your head around at first. However, once you understand how shaders work and how everything goes together, shader-based programming is vastly simpler to trying to do everything you want to do via fixed function.

Understand that the basic structure of a shader-based pipeline goes as such:

Geometry shader->Vertex shader->Fragment shader

Geometry shaders are still relatively new and supported only on newer hardware. Unless you have a need to perform dynamic generation or amplification of geometry via the graphics hardware, you don't need to worry about them (And I would say that, given the apparent development of your skill-set, trying to implement geometry shaders right now would be an error).

So, removing geometry shaders from the equation, you are left with vertex and fragment shaders.

Vertex shaders accept streams of input in the form of vertex definitions. You know, your vertex positions, normals, texture coordinates, etc... The shader is a program that operates on these vertices in some way. Typical operations include transforming them by the model/view/projection matrix chain, transforming texture coordinates via texture matrices, etc... Other calculations can be performed, such as vertex-based lighting, etc... The output of a vertex shader includes data that is to be interpolated by the rasterizer in order to generate the inputs for the fragment shader.

The fragment shader operates on fragments, which roughly correspond to "pixels", hence the alternative name of pixel shader. It accepts input as the interpolated values output by the vertex shader, including interpolated vertex positions, interpolated vertex colors, interpolated texture coordinates, etc... These inputs are then used to generate the final color/depth/alpha values for the given pixel that are drawn to the render buffer and depth buffer.

In fragment shaders, you are allowed to access texture data. (Later versions of the shading paradigm allow texture access in vertex shaders, ie for displacement and other effects, but we'll not worry about that). Given the computed texture coordinates, a texture can be sampled to obtain a texture value that can then be operated upon in some way.

Looking at the example you linked, you can see that the tutorial presents a very simple vertex shader that accepts the input vertex data, transforms it by the matrix chain, then passes on the transformed vertex and passes through a single set of texture coordinates. Then in the fragment shader, the interpolated texture coordinates are used to sample the texture. The remainder of the shader then simply does a test to see if the color value sampled from the texture is equal to the color red (red=1, green=0, blue=0). If this is the case, the fragment is discarded; ie, the shader exits without writing any output data to the render buffer.

It is a very simple example, but it requires a few things. First, you need to ensure that your hardware actually supports the shader language required, you need to ensure that Glew (or whatever extension assistant library is used) is initialized (yes, I remember your previous thread), and that your graphics environment is all good to go. If Glew fails to obtain the extension pointers, then you can not use shaders. Once you are assured that the relevant extensions are supported, the programs are successfully compiled, etc... then you can bind your vertex streams, your texture samplers, etc... and render your primitives.

In order to see anything on screen, you need to ensure that your model/view/projection matrices are set to sane values, and that the rendered geometry is actually visible on screen. You need to ensure that you have a texture bound to the named sampler in the GLSL shader (in this case it is called myTexture). If you don't bind a texture, it won't work.

Now, all that being said, I feel like I need to add this: shader-based colorkeying is kind of ass-backwards. You can write a utility function to convert a color key to an alpha channel, and use simple fixed-function with alpha blending to exclude the color keyed parts, no shaders needed. If color-keying is your sole reason for needing a shader, then perhaps you can make do without. Of course, given that shaders are the way of the future, you'll probably want to learn them anyway.

Topic Locked