OpenGL's ARB_vertex_program

UnknownStranger · 05-26-2003, 11:24 AM

<html>

OpenGL’s
ARB_vertex_program

0x01: Introduction
0x02: Interface
0x03: The ARB_vertex_program assembly language
0x04: A more detailed view over the API calls
0x05: Lets master the ARB_vertex_program assembly language

0x01: Introduction

This tutorial assumes that you already know about the programmable vertex pipeline; I’m not going to explain this here.
If you lack knowledge about this, take a look at Nvidia’s developer site. (You will also find good articles about this topic at Gamasutra.)

Well…now, that you’ve got a basic understanding about programmable pipelines…lets examine this tutorial’s topic…the ARB_vertex_program extension.

This extension was approved by the ARB on June 18, 2002, it’s both supported by Nvidia and ATI. (supported by all cards since GF3)

It contains 2 main parts: The interface between an OpenGL application and a vertex program, and the vertex program assembly language specifications.

Lets start with the interface part…

0x02: Interface

Well, lets take a look at the initializing(and closing) functions we’ve got…

glGenProgramsARB: Similar to glGenTextures; same syntax, (more or less) same functionality…generates memory for a vertex program.
glProgramStringARB: Takes a string, containing the Vertex Program assembly code, and compiles it to machine code, which is added to the currently bound Vertex Program.
glBindProgramARB: Same as glBindTexture; just for Vertex Programs…

glDeleteProgramsARB: Deletes programs, created with GenPrograms.

Ok, and now lets check the functions we’re going to use for parameter handling…
VertexAttrib...ARB: Passes up to 16 float[4] parameters per vertex to the vertex program, which are there handled as generic vertex attribute.
ProgramEnvParameter...ARB: Passes parameters to the environment parameters set(96+ float[4] variables, used by all VPs).
ProgramLocalParameter...ARB: Passes parameters to the local parameters set(96+ float[4] variables, used by the currently bound VP).

There are a few additional API calls, but we will concentrate on this few here currently.

Next, what’s the order of events, when creating vertex programs?

Well, it’s pretty simple…
We start by allocating space for one vertex program, and then binding the newly create vp:

unsigned int VP;
glGenProgramsARB(1,&VP);
glBindProgramARB(GL_VERTEX_PROGRAM_ARB,VP);
Then we read in a file. (You can avoid this by writing the vp code directly into a constant string in your program)

Next we compile the vp code.
(Program is a pointer to an ASCII string, containing the code)

glProgramStringARB(GL_VERTEX_PROGRAM_ARB,GL_PROGRA M_FORMAT_ASCII_ARB,strlen(Program),Program);

That’s it; we’ve now loaded and compiled our vertex program code, and are now ready to use it!

Well, now, lets take a look at a typical render function…

First we bind the vp we want to execute(if you only use one VP, it’ll still be bound after the initializing part, so you don’t need to do this again);
Then we enable GL_VERTEX_PROGRAM_ARB; this tells OpenGL, to use the currently bound vertex program, instead of the fixed function pipeline.

glBindProgramARB(GL_VERTEX_PROGRAM_ARB,VP);
glEnable(GL_VERTEX_PROGRAM_ARB);

After some drawing, we might want to stop using the vp; this is easily done with:

glDisable(GL_VERTEX_PROGRAM_ARB);

Well, that’s it; it can be that easy!
Next we will take a look at the vertex program assembly language, and then we’ll come back to the interface, and learn how to pass parameters to vertex programs, and about the remaining API calls!

0x03: The ARB_vertex_program assembly language

As the title already says, you program vertex programs with a assembly like language.

Though there are already high level languages for programming vertex and fragment programs available, you still might to have some knowledge about the assembly instructions, for example to be able to handtune some compiled high level code.

Ok, before we start with a simple example of such a program…lets take a look, what vertex programs are actually supposed to do…
The programmable pipeline bypasses the following parts, so that’s what we have to do on our own:

- The modelview and projection matrix vertex transformations.

- Vertex weighting/blending (ARB_vertex_blend).

- Normal transformation, rescaling, and normalization.

- Color material.

- Per-vertex lighting.

- Texture coordinate generation and texture matrix transformations.

- Per-vertex point size computations in ARB/EXT_point_parameters

- Per-vertex fog coordinate computations in EXT_fog_coord and NV_fog_distance.

- Client-defined clip planes.

- The normalization of AUTO_NORMAL evaluated normals

- All of the above, when computing the current raster position.

Maybe lets start with a simple example code, to see what’s going to await us…

!!ARBvp1.0

#Input
ATTRIB InPos = vertex.position;
ATTRIB InColor = vertex.color;

#Output
OUTPUT OutPos = result.position;
OUTPUT OutColor = result.color;

PARAM MVP[4] = { state.matrix.mvp }; # Modelview Projection Matrix.
TEMP Temp;

#Transform vertex to clip space
DP4 Temp.x, MVP[0], InPos;
DP4 Temp.y, MVP[1], InPos;
DP4 Temp.z, MVP[2], InPos;
DP4 Temp.w, MVP[3], InPos;

#Output
MOV OutPos, temp;
MOV OutColor, InColor;

END
The first code line you’ll find in an ARB_vertex_program code is this one here:

!!ARBvp1.0
This declares the vertex program version we are using(currently there’s only the 1.0 version)…this line is called the header string; here is where the vertex program starts.

Right at the end of the program we see another required string…

END

This marks…surprise…the end of a vertex program.

Ok, now before we proceed, maybe lets state 3 things:

-> Vertex programs are case sensitive; ADD is not the same as add
-> Vertex programs use # as comment tag
-> Every instruction is completed with a ‘;’

Ok, now lets go on with some explanation…

#Input
ATTRIB InPos = vertex.position;
ATTRIB InColor = vertex.color;

Here we declare 2 vertex attribute variables, and bind them to specific per vertex data, it’s position, and it’s color;

#Output
OUTPUT OutPos = result.position;
OUTPUT OutColor = result.color;

Here we do something similar, just instead of incoming data, we declare “references” to specific output data(again the vertex’s position and color).

PARAM MVP[4] = { state.matrix.mvp }; # Modelview Projection Matrix.
TEMP Temp;

And here we do 2 things…First we declare a parameter variable called MVP, which we bind OpenGL’s Modelview Projection Matrix to.

Well, about parameters…I’ll use a quotation out of the extension registry, since I’m not able(at least not at this time currently[pretty late right now ^^]) to formulate a better explaination

“Vertex program parameter variables are a set of four-component floating-point vectors used as constants during vertex program execution. Vertex program parameters retain their values across vertex program invocations, although their values can change between invocations due toGL state changes.“

The next thing we do is, to declare a TEMP variable; finally a variable where we can write data to…

(Temp variables are 12+ float[4]s)

And now, finally, we get to some code that actually “does” something…

#Transform vertex to clip space
DP4 Temp.x, MVP[0], InPos;
DP4 Temp.y, MVP[1], InPos;
DP4 Temp.z, MVP[2], InPos;
DP4 Temp.w, MVP[3], InPos;

#Output
MOV OutPos, Temp;
MOV OutColor, InColor;

Well, that’s more or less the most basic stuff you have to do with a vertex program…since we bypass the fixed function pipeline, we also bypass all it’s matrix calculations; so we have to do the transform of single points in 3D space to clip space…to do this, we calculate 4 4-component dot products(DP4), to transform each single vertex position with the mvp-matrix…(the matrix indizes access each column)

Here we clearly see the syntax of this language…

First comes the instruction, then the instruction’s destination, and then all, by the instruction required, sources.

What we also see is, that we can mask, which components of the destination variable we want to be written.
(For example DP4 Temp.x, MVP[0], InPos; computes the 4 component dot product of the original vertex pos and the first column of the modelview projection matrix, and saves the result only in the destination variable(Temp)’s x value.)
(More about this in Chapter 0x05)

After we performed the transforms(which we saved in a temporary variable), we pass the new position, and the vertex’s color forward, to the rest of the graphics pipeline.

Ok, now we know the basic OpenGL commands for handling vertex programs, and we know, how vertex programs look like, and how they operate…so, lets take some deeper looks at this pretty complex topic…

</html>

UnknownStranger · 05-26-2003, 11:29 AM

Well, actually I wanted to finish all 5 chapters before releasing this article(especially since the last two are the most important, and longest ones...

);

But I haven't got much time within the next few weeks(school's making me pretty busy currently); so I decided to release the introduction chapters...maybe lets call it a little teaser ;7

Well, anyway...hope you like this article(though it doesn't contain much important stuff yet...

)...

I promise to finish the last 2 chapters as soon as possible...

Dia Kharrat · 05-26-2003, 04:06 PM

nice work AoD!

Looking forward to the rest of the tutorial

(btw, posted some news on the main page)

Noor · 05-26-2003, 04:37 PM

Thank you so much

Looking forward to the rest of the tutorial.

UnknownStranger · 05-26-2003, 10:22 PM

Thx for the nice feedback guys...

Well, since I have only done a little bit of the other 2 chapters, you can influence their "development", and tell me, what you'd like to hear... ;7
Chapter 4 will be just a more detailed overview about the API calls, and about parameter passing;

But chapter 5 will get interessting... B)

I thought about starting with some general overview about the instructions and variables/parameters; but then I want to implement stuff like diffuse and specular lighting in vertex programs, and then explain them; both the code and the theory behind it(i hope my math skills will be good enough

)

Halloko · 06-13-2003, 02:26 PM

Weee.. thanx bunch for those articles, Angel_of_Death.
I've been searching through the web for several days now and I haven't found a good tutorial on the ARB vertex shader language yet.. at least not until now

Some comments on future articles:
- How to do per-pixel lighting using the ARB extensions (I think the net REALLY lacks tuts on this subject)
- Bump-mapping

Hope you're considering my suggestions, since it seems you have an understanding of shaders and it would be sooo great if you could write some articles on this subject

anubis · 06-13-2003, 02:53 PM

as i know him... he'll work overtime after he read your post

UnknownStranger · 06-14-2003, 01:23 AM

Thx Halloko

Well, about your suggestion...

If you mean you would like an ARB_fragment_program tutorial, I'm sorry; but since my Graphics card doesn't support that extension I'm not planning to write any article about it...

But if you mean just per pixel lighting with any ARB extension, this might help you:
http://users.ox.ac.uk/~univ1234/tutorials/.../simplebump.htm

It shows how to create bump mapping effects by using the following extensions:
ARB_multitexture
ARB_texture_cube_map
ARB_texture_env_combine
ARB_texture_env_dot3

And if you want an article about using both vertex programs and these extensions...I'm already thinking about some examples to code...

05-26-2003, 11:24 AM	#1
UnknownStranger Valued Member Join Date: May 2003 Location: Austria Posts: 140	<html> OpenGL’s ARB_vertex_program 0x01: Introduction 0x02: Interface 0x03: The ARB_vertex_program assembly language 0x04: A more detailed view over the API calls 0x05: Lets master the ARB_vertex_program assembly language 0x01: Introduction This tutorial assumes that you already know about the programmable vertex pipeline; I’m not going to explain this here. If you lack knowledge about this, take a look at Nvidia’s developer site. (You will also find good articles about this topic at Gamasutra.) Well…now, that you’ve got a basic understanding about programmable pipelines…lets examine this tutorial’s topic…the ARB_vertex_program extension. This extension was approved by the ARB on June 18, 2002, it’s both supported by Nvidia and ATI. (supported by all cards since GF3) It contains 2 main parts: The interface between an OpenGL application and a vertex program, and the vertex program assembly language specifications. Lets start with the interface part… 0x02: Interface Well, lets take a look at the initializing(and closing) functions we’ve got… glGenProgramsARB: Similar to glGenTextures; same syntax, (more or less) same functionality…generates memory for a vertex program. glProgramStringARB: Takes a string, containing the Vertex Program assembly code, and compiles it to machine code, which is added to the currently bound Vertex Program. glBindProgramARB: Same as glBindTexture; just for Vertex Programs… glDeleteProgramsARB: Deletes programs, created with GenPrograms. Ok, and now lets check the functions we’re going to use for parameter handling… VertexAttrib...ARB: Passes up to 16 float[4] parameters per vertex to the vertex program, which are there handled as generic vertex attribute. ProgramEnvParameter...ARB: Passes parameters to the environment parameters set(96+ float[4] variables, used by all VPs). ProgramLocalParameter...ARB: Passes parameters to the local parameters set(96+ float[4] variables, used by the currently bound VP). There are a few additional API calls, but we will concentrate on this few here currently. Next, what’s the order of events, when creating vertex programs? Well, it’s pretty simple… We start by allocating space for one vertex program, and then binding the newly create vp: unsigned int VP; glGenProgramsARB(1,&VP); glBindProgramARB(GL_VERTEX_PROGRAM_ARB,VP); Then we read in a file. (You can avoid this by writing the vp code directly into a constant string in your program) Next we compile the vp code. (Program is a pointer to an ASCII string, containing the code) glProgramStringARB(GL_VERTEX_PROGRAM_ARB,GL_PROGRA M_FORMAT_ASCII_ARB,strlen(Program),Program); That’s it; we’ve now loaded and compiled our vertex program code, and are now ready to use it! Well, now, lets take a look at a typical render function… First we bind the vp we want to execute(if you only use one VP, it’ll still be bound after the initializing part, so you don’t need to do this again); Then we enable GL_VERTEX_PROGRAM_ARB; this tells OpenGL, to use the currently bound vertex program, instead of the fixed function pipeline. glBindProgramARB(GL_VERTEX_PROGRAM_ARB,VP); glEnable(GL_VERTEX_PROGRAM_ARB); After some drawing, we might want to stop using the vp; this is easily done with: glDisable(GL_VERTEX_PROGRAM_ARB); Well, that’s it; it can be that easy! Next we will take a look at the vertex program assembly language, and then we’ll come back to the interface, and learn how to pass parameters to vertex programs, and about the remaining API calls! 0x03: The ARB_vertex_program assembly language As the title already says, you program vertex programs with a assembly like language. Though there are already high level languages for programming vertex and fragment programs available, you still might to have some knowledge about the assembly instructions, for example to be able to handtune some compiled high level code. Ok, before we start with a simple example of such a program…lets take a look, what vertex programs are actually supposed to do… The programmable pipeline bypasses the following parts, so that’s what we have to do on our own: - The modelview and projection matrix vertex transformations. - Vertex weighting/blending (ARB_vertex_blend). - Normal transformation, rescaling, and normalization. - Color material. - Per-vertex lighting. - Texture coordinate generation and texture matrix transformations. - Per-vertex point size computations in ARB/EXT_point_parameters - Per-vertex fog coordinate computations in EXT_fog_coord and NV_fog_distance. - Client-defined clip planes. - The normalization of AUTO_NORMAL evaluated normals - All of the above, when computing the current raster position. Maybe lets start with a simple example code, to see what’s going to await us… !!ARBvp1.0 #Input ATTRIB InPos = vertex.position; ATTRIB InColor = vertex.color; #Output OUTPUT OutPos = result.position; OUTPUT OutColor = result.color; PARAM MVP[4] = { state.matrix.mvp }; # Modelview Projection Matrix. TEMP Temp; #Transform vertex to clip space DP4 Temp.x, MVP[0], InPos; DP4 Temp.y, MVP[1], InPos; DP4 Temp.z, MVP[2], InPos; DP4 Temp.w, MVP[3], InPos; #Output MOV OutPos, temp; MOV OutColor, InColor; END The first code line you’ll find in an ARB_vertex_program code is this one here: !!ARBvp1.0 This declares the vertex program version we are using(currently there’s only the 1.0 version)…this line is called the header string; here is where the vertex program starts. Right at the end of the program we see another required string… END This marks…surprise…the end of a vertex program. Ok, now before we proceed, maybe lets state 3 things: -> Vertex programs are case sensitive; ADD is not the same as add -> Vertex programs use # as comment tag -> Every instruction is completed with a ‘;’ Ok, now lets go on with some explanation… #Input ATTRIB InPos = vertex.position; ATTRIB InColor = vertex.color; Here we declare 2 vertex attribute variables, and bind them to specific per vertex data, it’s position, and it’s color; #Output OUTPUT OutPos = result.position; OUTPUT OutColor = result.color; Here we do something similar, just instead of incoming data, we declare “references” to specific output data(again the vertex’s position and color). PARAM MVP[4] = { state.matrix.mvp }; # Modelview Projection Matrix. TEMP Temp; And here we do 2 things…First we declare a parameter variable called MVP, which we bind OpenGL’s Modelview Projection Matrix to. Well, about parameters…I’ll use a quotation out of the extension registry, since I’m not able(at least not at this time currently[pretty late right now ^^]) to formulate a better explaination “Vertex program parameter variables are a set of four-component floating-point vectors used as constants during vertex program execution. Vertex program parameters retain their values across vertex program invocations, although their values can change between invocations due toGL state changes.“ The next thing we do is, to declare a TEMP variable; finally a variable where we can write data to… (Temp variables are 12+ float[4]s) And now, finally, we get to some code that actually “does” something… #Transform vertex to clip space DP4 Temp.x, MVP[0], InPos; DP4 Temp.y, MVP[1], InPos; DP4 Temp.z, MVP[2], InPos; DP4 Temp.w, MVP[3], InPos; #Output MOV OutPos, Temp; MOV OutColor, InColor; Well, that’s more or less the most basic stuff you have to do with a vertex program…since we bypass the fixed function pipeline, we also bypass all it’s matrix calculations; so we have to do the transform of single points in 3D space to clip space…to do this, we calculate 4 4-component dot products(DP4), to transform each single vertex position with the mvp-matrix…(the matrix indizes access each column) Here we clearly see the syntax of this language… First comes the instruction, then the instruction’s destination, and then all, by the instruction required, sources. What we also see is, that we can mask, which components of the destination variable we want to be written. (For example DP4 Temp.x, MVP[0], InPos; computes the 4 component dot product of the original vertex pos and the first column of the modelview projection matrix, and saves the result only in the destination variable(Temp)’s x value.) (More about this in Chapter 0x05) After we performed the transforms(which we saved in a temporary variable), we pass the new position, and the vertex’s color forward, to the rest of the graphics pipeline. Ok, now we know the basic OpenGL commands for handling vertex programs, and we know, how vertex programs look like, and how they operate…so, lets take some deeper looks at this pretty complex topic… </html> ___________________________________________ M.E. ----- "Human stupidity is something you can rely on." -- M.A. "I didn't design life." -- J.G. "It's almost finished..." -- EHD

05-26-2003, 11:29 AM	#2
UnknownStranger Valued Member Join Date: May 2003 Location: Austria Posts: 140	Well, actually I wanted to finish all 5 chapters before releasing this article(especially since the last two are the most important, and longest ones... ); But I haven't got much time within the next few weeks(school's making me pretty busy currently); so I decided to release the introduction chapters...maybe lets call it a little teaser ;7 Well, anyway...hope you like this article(though it doesn't contain much important stuff yet... )... I promise to finish the last 2 chapters as soon as possible... ___________________________________________ M.E. ----- "Human stupidity is something you can rely on." -- M.A. "I didn't design life." -- J.G. "It's almost finished..." -- EHD

05-26-2003, 04:37 PM	#4
Noor Senior Member Join Date: Jan 2003 Location: ON, Canada Posts: 524	Thank you so much Looking forward to the rest of the tutorial. ___________________________________________ "What ever happened to happily ever after?"

05-26-2003, 10:22 PM	#5
UnknownStranger Valued Member Join Date: May 2003 Location: Austria Posts: 140	Thx for the nice feedback guys... Well, since I have only done a little bit of the other 2 chapters, you can influence their "development", and tell me, what you'd like to hear... ;7 Chapter 4 will be just a more detailed overview about the API calls, and about parameter passing; But chapter 5 will get interessting... B) I thought about starting with some general overview about the instructions and variables/parameters; but then I want to implement stuff like diffuse and specular lighting in vertex programs, and then explain them; both the code and the theory behind it(i hope my math skills will be good enough ) ___________________________________________ M.E. ----- "Human stupidity is something you can rely on." -- M.A. "I didn't design life." -- J.G. "It's almost finished..." -- EHD

06-13-2003, 02:53 PM	#7
anubis DevMaster Staff Join Date: Apr 2003 Location: Germany Posts: 2,328	as i know him... he'll work overtime after he read your post ___________________________________________ If Prolog is the answer, what is the question ?

05-26-2003, 04:06 PM	#3
Dia Kharrat DevMaster Staff Join Date: Jan 2003 Posts: 1,201	nice work AoD! Looking forward to the rest of the tutorial (btw, posted some news on the main page)

06-13-2003, 02:26 PM	#6
Halloko New Member Join Date: Jun 2003 Posts: 8	Weee.. thanx bunch for those articles, Angel_of_Death. I've been searching through the web for several days now and I haven't found a good tutorial on the ARB vertex shader language yet.. at least not until now Some comments on future articles: - How to do per-pixel lighting using the ARB extensions (I think the net REALLY lacks tuts on this subject) - Bump-mapping Hope you're considering my suggestions, since it seems you have an understanding of shaders and it would be sooo great if you could write some articles on this subject

06-14-2003, 01:23 AM	#8
UnknownStranger Valued Member Join Date: May 2003 Location: Austria Posts: 140	Thx Halloko Well, about your suggestion... If you mean you would like an ARB_fragment_program tutorial, I'm sorry; but since my Graphics card doesn't support that extension I'm not planning to write any article about it... But if you mean just per pixel lighting with any ARB extension, this might help you: http://users.ox.ac.uk/~univ1234/tutorials/.../simplebump.htm It shows how to create bump mapping effects by using the following extensions: ARB_multitexture ARB_texture_cube_map ARB_texture_env_combine ARB_texture_env_dot3 And if you want an article about using both vertex programs and these extensions...I'm already thinking about some examples to code... ___________________________________________ M.E. ----- "Human stupidity is something you can rely on." -- M.A. "I didn't design life." -- J.G. "It's almost finished..." -- EHD

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode