Ich habe mir ein paar shader examples angesehen und ab jetzt verstehe ich shader weniger als erst.

- was sind vertex shader, und wo sind sie anzuwenden
- was sind pixel shader, und wo sind sie anzuwenden
- was ist das unterschied (between) vertex shader, pixel shader and textures.
- warum sind shader besser als textures?
- was ist glslang ist das die arb way fur shader?
- welcher hardwar mus man minmal habe? Auf meiner geforce ti4200 laufen keiner pixel shader?
- Gibt es ein art 'shader fur dummies' tutorial oder buch?

_________________
http://3das.noeska.com - create adventure games without programming

I'll hope you don't mind if I answer in english


Let me first set clean what a shader is : A shader is nothing else than a program that runs on a certain part of the OpenGL-pipeline. It's either written in an assembler-like language (ARB_VP/ARB_FP) or a high level shading language like glSlang.
A vertex shader therefore is a small program that "does something" with a vertex. And a pixel shader (called fragment shader under the GL, which suits the function much better) is a small program that "does something" with a fragment (the term pixel isn't totall right, since you can also for example do something with the depth of a fragment).

What can be done in a shader is very different, and depends on what you want to do. In a pixel shader for example you can easily do your own per-pixel lighting (OpenGL itself can only do per-vertex lighting, except for some tricks like cubemaps). Or in a vertex shader you can for example change the way how OpenGL's projection works, to make an fisheye-view. You can even change the vertices of a displaylist with a vertexshader, case the vertexshader always gets executed on all vertices, no matter how they are stored or used.


A texture is always static, but as said abive, with a shader you can dynamically change vertices or fragments during the runtime of your application. And shaders can do much more than only change textures. Your possibilites are almost unlimited (but kind of limited by the hardware you use). You can do your own lightingcalculations, generate dynamic materials, generate shadows in a shader, and so on.


glSlang is a high-level shadinglanguage. The ARB-way to write shaders is an assembler-like language that is exposed through GL_ARB_Vertex_Program and GL_ARB_Fragment_Program. glSlang is a C-language for shaders, and therefore easier to use than the assembler-like ARB_VP/ARB_FP.


OpenGL only supports vertex-/pixelshader 2.0 trough it's vendorindependend extensions (ARB_VP/ARB_FP, glSlang), and your GF4 only supports PS1.3. That shaderversion can be used through some nvidia extensions like textureshaders, NV_Vertex_Program and the registercombiners. But as said they only work on NVidia-cards and are not as flexible than glSlang or ARB_VP/FP.


Nothing that I know of. The hardest part with shaders is not the shaders itself (cause the language in which they are written is very simple and only has very few commands), but what is done with shaders. Normally you do complex calculations in a shader to achieve things like per-pixel-lighting, bumpmapping and so on. The hardest part is therefore the technique behind those calculations and not the shaderlanguage itself.

I hope this clears the things up a bit. But that topic is hard do describe, especially if you don't know what you would do with a shader. I suggest you to take a look at NVidia's developersection, where they have documentation on this topic that should help you understand what shaders are and what they're used for.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Let me make some additions to SoS detailed explanation:

Contrary to CPU's the first GPU's weren't programmable. Instead, they had a fixed function pipeline. This means that the only possibility you had to controll what the card did with the data you fed her, was by setting parameters and flags. Every feature, from texturing to bumpmapping was integrated directly into the hardware. If one wanted new techniques supported one needed do build new GPUs, write new drivers and update the Api. (Extension for OpenGL - ordinary Updates for DirectX)

Since DirectX 8 class GPUs this is slowly changed. Significant parts of the graphic-pipeline get replaced with programmable units to give the developer more flexibility. There are two separate programmable units in nowadays graphiccards: Vertex processors (Tranformation, Lighting etc) and Fragment processors (Texturing, Coloring). The rest (Projecting, Clipping, Depthtest, Alphablending etc) is still done by the fixed pixelpipeline.

Now, good to know that these things exist but how do we, the developers programm these units? That's where shaders come into play. You write VertexShaders for the Vertexprocessor and PixelShaders for the Fragmenteprocessor. You can do so via Assembler or in a High-Level-Shadinglanguage. After compiling you can "install" them on your graphiccard at runtime and thus controll what exactly the graphiccard does with the data you feed to her.

The only problem is that you need a good understanding of computergraphics to replace the fixed function pipeline with your own code/ideas.

You might want to try (until Rendermonkey 1.5 with glSlang support is released) the Nvidias FXComposer which is a nice playground if you want to experiment with shaders. (if you manage to get a dx9 card - otherwise it's not much fun.)

_________________
Selber Denken macht klug!

another addition: the Mesa 6.01 release provides a stable software implementation of GL_ARB_vertex_program and GL_ARB_fragment_program, which suffices to get started on older video cards.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/