this glsl 1.3 thing

ok, its the first time I’ve looked at it. Don’t really pay attention to the API wars. First impression…noob time. :slight_smile:

The thing that strikes me is all the built in uniform state stuff is deprecated? gl_ModelViewProjectionMatrix is depreciated. Do I call ftransform instead? Are there new built in names for these variables?

I don’t like to have to program uniforms all the time. It requires a compile. I suppose avoiding a compile is what scripting is all about.

Often, I need to make a filter. You have to make a kernel. I end up having to make a uniform variable like k[4][4] for a filter – a compile. But I would like this in my script. So, can I do something like this? This would be a time saver.

float k[4][4] = {
{1,2,3,4},
{1,2,3,4},
{1,2,3,4},
{1,2,3,4}
};

Does Apple have example code for the opengl 3.0 stuff? Trying to get on the same wavelength or anticipate where this is going. :slight_smile:

  1. There is no OpenGL 3.0 on Apple yet and probably won’t be there for at least half a year (but who knows).

  2. In GL3.0 all fixed-function was deprecated. GLSL 1.30 reflects this by removing the corresponding features.

  3. Why does “programming uniforms requires a compile”? And GLSL is not scripting. Can you elaborate?

  4. You will have to ask someone else if there are array constants in GLSL, I don’t know…

Hmm, your right its not scripting. The program is being complied and not interpreted.

Have not read enough of the spec to probably comment about it. But all the depreciated stuff caught my eye and made me curious.

I suppose what I mean is if I’m going to pass in something with a uniform then I have to go into my c and c++ code and make a change. eg. glUniformxx (?) Thus, a recompile. But if its a built in uniform state variable, I just use it. So, all these state variables are gone and I’m now have to make a uniform call.(?) Unless, I’m really missing the point why they depreciated them. Hmm, the point is the fixed pipeline is gone. :slight_smile: ok, so am I to compute say modelviewprojection matrix by hand? No more glTranslate, glRotate etc. Then pass in the matrix I make to the script? Looks like I’m confused.

Maybe, having less of these uniforms makes things faster and drivers simpler. If drivers are simpler then the driver is probably more bug free which would be a good thing. But this situation might take a little more work for the application developer but potential more flexible.

The version of glsl on my mac is 1.2. The matrix example shown above is a compile error. Think that syntax is not accepted. Would be nice, though.

I’ll just have to read up some more on this. Don’t want to be a whiner. :slight_smile:

hmmm, I don’t understand anything you say… but do you understand what Zengar said, it is pretty clear.

And shader is not “recompilated” after setting a uniform, it does only some optimization, which is apparently a performance issue until 3.0 but would be fixed in the next release.

You don’t recompile when you change a uniform.
You need to bind the shader (glUseProgram) and then upload the uniform (glUniformXX) and that’s all.

For matrices, you use a math library to generate the matrices you need and upload them as uniforms.

Yes, it takes more work from the developer.

Been reading a little more. I understand the flat,smooth,in, out stuff.

I’m a little confused by :

in int gl_VertexID;

is going to be:

vec4 v = mymatrix[gl_VertexID]; //? where is mymatrix?

This is an index into some type of array. But what array? Wait a minute here. :slight_smile: Am I passing in an array of uniforms or is there one defined?

I had gotten rid of my displays lists from before. Now, I’m using a vbo. So, gl_VertexID is an index into it somehow. I call glBufferData and set it to GL_STATIC_DRAW.

Also, when I mentioned compiling before I was alluding to when I would develop my code I would need to recompile all my c++ code to create a uniform. If I were using the state variables like in glsl 1.2 I’d just change the glsl text file that would be compiled during run time – not as painful.

I’m gonna explain what I think I know, and then probably complicate this further :slight_smile:

If you are avoiding the deprecated stuff I believe you need to keep track of your own modelview and projection matrices, and then pass them into your shaders with glUniformMatrix4f or whatever. Then you can use them in the same way you use the built in uniforms.

That of course does mean that you have some math library to make your life easier. You could actually emulate the current functionality by keeping your own homebrew matrix stacks and current matrices and implement your own MatrixMode, PushMatrix, PopMatrix, Translate etc.

The bit that I’m totally confused about with all this deprecation stuff is that glColor, glTexCoord and glColorPointer, glTexCoordPointer etc. have all been deprecated, how do I send colours/texcoords to my vertex shader if I’m rendering with VBOs? (The answer to this is quite likely obvious, it’s early in the morning here and I haven’t had a coffee)

OK, I’m gonna answer my own question here. glVertexAttribPointer is not deprecated (I thought it was because in the spec it says glVertexAttrib* is, I guess the * doesn’t mean everything beginning with glVertexAttrib :slight_smile: )

So that’s how you send the colors etc. but now I see glVertexPointer is deprecated, so how do we use VBOs? I’m so confused :stuck_out_tongue:

Actually that section says that the VertexAttrib* calls used for specifying current value of vertex attribute are not deprecated. It does not talk about the functions specifying the vertex arrays.

So that’s how you send the colors etc. but now I see glVertexPointer is deprecated, so how do we use VBOs? I’m so confused :stuck_out_tongue:

It is the same as with the colors. You use a generic attribute to pass that value. However there is one catch. You need to ensure that enabled array is attached to the generic attribute zero (which is equivalent of the VertexPointer array) or nothing should be drawn (at least I did not found change in that behavior in the OGL3 specification).

The value contains index of the vertex within the vertex array. You only need to use it if you wish to modify processing of the vertex based on its index within the vertex array. What you do with it is entirely up to you, it is just a value.

[quote]
So that’s how you send the colors etc. but now I see glVertexPointer is deprecated, so how do we use VBOs? I’m so confused :stuck_out_tongue:

It is the same as with the colors. You use a generic attribute to pass that value. However there is one catch. You need to ensure that enabled array is attached to the generic attribute zero (which is equivalent of the VertexPointer array) or nothing should be drawn (at least I did not found change in that behavior in the OGL3 specification). [/QUOTE]

OK cool that makes sense, onto my next deprecation question (sorry about hijacking this thread a little) how do we replace GL_CLAMP?

By GL_CLAMP_TO_EDGE

I see the gl_MultiTexCoordX is depreciated. So, I should replace my calls to glTexCoordPointer with glVertexAttribPointer.

Then in my new glsl code I use the keyword “attribute”. atrribute is different on a per vertex basis. Whereas a uniform is the same over the programs entire execute. For instance, in bump mapping …

attribute vec3 t;
attribute vec3 b;
attribute vec3 n; //looks like gl_Normal is depreciated too. Need to pass in?


I’m doing something like this currently:

glClientActiveTexture(GL_TEXTURE1);
glBindBuffer( GL_ARRAY_BUFFER, _vbo_id );
glTexCoordPointer( 3, GL_FLOAT, 0, (char *) NULL );
glEnableClientState(GL_TEXTURE_COORD_ARRAY);

//do more stuff

glDrawArrays( GL_TRIANGLES, 0, _verts );

I suppose it would change to something like:

glEnableVertexAttribArrayARB( 1 );
glBindBuffer( GL_ARRAY_BUFFER, _vbo_id );
glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 0, (char *) NULL );

glEnableClientState(GL_TEXTURE_COORD_ARRAY); //??? does this matter anymore

//do more stuff

glDrawArrays( GL_TRIANGLES, 0, _verts );

Shoot it says built in “attributes” are depreciated. ok, so I defined the attribute. There must be a call to map that to atrrib array to 1. Or do I use glGetUniformLocation or something like that? I bet glEnableVertexAttribArray is using one of those depreciated built ins. Sorry about the confusion. Dealing with the effect of a glsl lobotomy. :slight_smile:

You can either explicitly bind attributes to attribute indices with glBindAttribLocation before linking a program. Or you can let the OpenGL implementation assign locations during linking and get them with glGetAttribLocation.

One other question. I notice gl_TextureMatrix is depreciated.

I like this variable because I could write to it once before I draw the frame and all my glsl programs could access it. I’d store my texture matrix there for instance. Maybe a frame counter – not necessarily texture related stuff. So, I do something like this at the beginning of a frame:

glActiveTexture(GL_TEXTURE5);
glMatrixMode(GL_TEXTURE);
glLoadMatrixf(temp[0]);
glMatrixMode(GL_MODELVIEW);
glActiveTexture(GL_TEXTURE0);

Is there a new mechanism to write out to all programs once? If I make a uniform to each program then I’ve got to keep track where to write the uniform and I would have to write a uniform to each program. If I can write once then things are faster.

Did some more reading. Not trying to make a monolog here. The trials and tribulations of prepping my opengl code.

But it looks like I’m suppose to replace the “attribute” with “in”. Also, ftransform will be gone and I’m suppose to add “invariant” to an “out”. I think the glEnableClientState is fixed pipeline stuff so I get rid of it. But I’m a little confused because at some point I have to enter vertex data … I need to tell it its vertex data. The rest is attributes I suppose.

For now, in glsl 1.2, I pass my tangent data as a vertex attribute. ( for tbn stuff ) I get the normal from gl_Normal and can calculate the binormal with a cross product. So, I figure in the future I make the normals an attribute ( or “in” ) But I don’t think I can make the normal and tex coords an attribute with 1.2. Made my program freak out with textures on the nvidia card.

I suppose calls to glMaterialfv need to be replaced by a uniform. Funny, but people’s glsl scripts are sure going to look different from each other when all these built in state variables are gone.

I wonder if I could pass in a texture and then use gl_VertexID with it. Like looking at an array of data? That certainly might be easier than all these funny calls. Plus, a texture is in viedo memory which is fast. Sort of like a vbo.

If I recall, OpenGL 3.0 has multisample for FBOs? Currently, I make my FBO twice as big then copy it down to the smaller frame buffer to get a anti aliasing down sample effect. Sure would not mind using a smaller buffer.

The only way in which you can change content of standard uniform variable in more than one program is to use the EXT_bindable_uniform extensions (currently Nvidia GF8+ only ).

What do you mean with the “vertex data”? The vertex position is for the shader just another attribute.

So, I figure in the future I make the normals an attribute ( or “in” ) But I don’t think I can make the normal and tex coords an attribute with 1.2. Made my program freak out with textures on the nvidia card.

With what error the program failed? The Nvidia has some aliasing between the generic attributes and the built-in attributes. It is not possible (at least it was not possible some time ago) to use generic attribute (bound using the glBindAttribLocation) and its aliased built-in attribute at the same time on Nvidia card.

I wonder if I could pass in a texture and then use gl_VertexID with it. Like looking at an array of data? That certainly might be easier than all these funny calls.

You can use to use the gl_VertexID to index into a texture however unless you have some special reason to do so, putting the data directly inside the vertex array should be more effective.

This part was confusing me – the actual vertex data. Must of created a conflict with the aliasing you described.

I suppose in 3.0 it would convert to an attribute like everything else :

glBindAttribLocation (program_object, 4, “vbo_vertex”); // in vec3 vbo_vertex;


glEnableVertexAttribArray(4);


glBindBuffer( GL_ARRAY_BUFFER, _vbo_id );
glVertexAttribPointer(4, 3, GL_FLOAT, GL_FALSE, 0, (char *) NULL );

//Now you don’t need the gl_Vertex anymore.

I was trying glVertexAttribPointer for vertex, normal, texcoord, and tangent but the textures were not showing up in 1.2. Probably because of the aliasing conflict. Plain colors seemed to work.

Hmm, these vbo/ uniform changes do not seem that bad. But the matrix changes do worry me. eg. getting rid of glRotate etc. There is vvector.h which has been useful. I’d like to make a class that uses accelerate library for the matrix stuff. This is a good project for the open source folk. Might take a little more work. Just a search and replace on those calls – sprinkled everywhere. Then a glUniformMatrix call to get the data into the shader – I’d have to call this for every shader.

I’ll just have to incrementally change these things. When 3.0 arrives on the mac, I’m sure the compiler might give a depreciation warning message and that will be a motivator for people. :slight_smile: