I’m investigating it for my final year project at university but am finding it incredibly difficult to find decent resources on it. I’ve seen the OpenGL 1.4 specs but I really want a tutorial.
There are a finite number of vertex program asm instructions, and very simple syntax rules - so where’s the problem?
MUL a,b,c = multiply b by c and store the result in a.
it’s a doddle!
Where do you learn these rules and instructions? I don’t know any!
Referring to your example, why would you want to multiply b by c anyway? Why not just use the standard way of multiplying (b*c)?
[This message has been edited by Billy Lee (edited 11-18-2002).]
Where do you learn these rules and instructions?
You read the specs to the vertex shader assembly languages. Grab the ARB_vertex_program spec, read it for a couple of hours and off you go.
Referring to your example, why would
you want to multiply b by c anyway?
Lol, why not? You can do lots of nice things by multiplying things together. Say b and c are colors and you want to modulate them.
Why not just use the standard way of multiplying (b*c)?
Because * is not a legal assembly instruction in any vertex assembly language.
You can write (b * c) in the DX9 HLSL or in Cg, but those are high-level shading languages.
The reason you can’t do a=b*c is because, as has been pointed out, this is a high level way of describing the operation. Vertex programs are modelled on assembly language because they have a small number of registers, and they have to be efficient - because they operate on huge amounts of data (your vertices), and also they have a very limited maximum number of allowed instructions. Exposing the functionality as an assembly language makes sure people take care when writing them, as seemingly simple operations in a high level language can use up a huge number of assembly instructions, which will bring your rendering performance to its knees without you being fully aware as to why.
Just think of it as programming a sinclair ZX81 - you’d have been crazy to use a high level language with that, simply because you were so limited in clock cycles that you needed to know exactly what the CPU was doing, and how long it was taking to do it.
[This message has been edited by knackered (edited 11-18-2002).]
It’s Direct3D, but it offers an excellent grasp of the vertex program (shader in this case) and the philosophy behind it.
developer.nvidia.com (get the SDK)
or cvs1.nvidia.com for the individual folders.
vertex programming is nothing complex if you know ASM languages. I think your problem will be what do do to get the effect you want.
Here’s a short explanation :
Read from v, output to o in vs files and setup your program states in the vsp files.
In your cpp (or c) file call the attribute functions to setup some of the contents of the registers. The c registers can be used in any way you like. The programmer must decide which register serves what purpose. There is a limit to how many instrucion you can have and how many constants.
I have been skimming the demoes and the specs on my free time so I might be wrong.
One more thing, the more experience and knowledge you have about the opengl pipeline, texturing tricks and general knowledge of the physics of lighting, the better. Reading about the harware capabilities is good too in the end.
I’m in this same boat - the vertex/fragment shader code isn’t what I’m having difficulty with, it’s hooking it all up. Still having problems getting simple texture mapping working. See "Texture mapping w/vertex & fragment shaders " thread.