This glsl 1.3 thing

[nib]

Huff, this is all starting to jolt my memory.

Ironically, I used to have my own uniform names for material colors like specular, ambient, diffuse, etc. Because I migrated away from CG and I did not know what to expect in glsl. So, I made my own names. But that way sucked. I was constantly having to check the unform for the id and setting it on a shader by shader basis. I’d have to do that all up front and it was a pain. Of course, all these different shaders happened to have potential different uniform location numbers. Could not make an assumption using something like glBindAttribLocation where I could set the number up front – pretty sure I cant do that with uniforms. Hmm, unless its the order in which I declare the uniform in the shader program but I figure the compiler is going to assign the number.

Where as, with something like, gl_FrontMaterial.diffuse I’d just call

glMaterialfv(GL_FRONT_AND_BACK, GL_DIFFUSE, mDiffuse);

and populate gl_FrontMaterial.diffuse. Which is much more appealing to me. Plus, if I happened to switch to a different shader then I did not have to call the uniform again. The material values could of changed since I last used that shader.

Think this gets back to setting a uniform that shaders can share. So, I only set it once and not a zillion times. Huff, I don’t really want to change that.

Maybe, I’m totally missing the point again.

[nib]

GL_EXT_bindable_uniform would assign a uniform a number and not the compiler. Alas, its only supported in the highest end nvidia cards and the software renderer on the mac.

[nib]

Hmm, looking over my uniforms for materials. There is a place in my program where I set up the samplers. It looks for names of samplers there anyways. This is a good spot to check for my uniform names and migrate away. Put it all into a map structure. So, done with changing my uniforms with regard to materials. I see that light information is going to be deprecated too. More uniforms. Not using the fixed function pipeline anymore. Slowly swap it out little by little.

BTW, in the OpenGL Wikipedia there was a good vbo example under extensions. A couple typos but it really helped. I could do things faster.

[MrB]

By the way,
If you took a look at the OpenGL ES 2.0 specification, you would get a fairly good view of what the OpenGL 3.0 spec would look like with all of the fixed function actually removed.

So far, you are correct in saying that you need to use Bind/GetAttribLocation, in conjunction with VertexAttribPointer, and you will need to create user defined uniforms for all the fixed function state you were using.

Unfortunately, until uniform buffers (or something equivalent) are elevated to ARB extension or core status, you will have to set the uniforms for each program they are used in (and they will almost certainly have different uniform locations for each program) in order to be portable.

[bakura]

Hej !

Sorry if it has already been said, but I’m trying to understand GLSL 1.3.

I think I have understood the new in, out, inout, and the different interpolation qualifiers. However, I’m really lost with all those deprecated varying and uniform variables.

Here are the things I don’t understand :

in mat4x4 ModelViewProjectionMatrix;

invariant out vec4 gl_Position;

void main ()
{
   gl_Position = ModelViewProjectionMatrix * ????????
}

Same for texture mapping :

smooth out vec2 TexCoords;

void main ()
{
   TexCoords = ?????? gl_TexCoord[0] and gl_MultiTexCoordn are deprecated !!
}

Thanks ^^

[martinsm]

You define your own attributes instead of predefined:

in vec3 vertex_position;
uniform mat4x4 ModelViewProjectionMatrix;

void main ()
{
   gl_Position = ModelViewProjectionMatrix * vec4(vertex_position, 1.0);
}

[nib]

I ran into some odd behavior. I changed my materials from the default state to uniforms I passed in. The shader was generic. So, I would just set these uniforms. It was working.

Problems started when the scene would get complicated. I would set these uniforms too much and my frames would skip. I could hear the disk at the precise moment grind a little. It was like virtual memory was being triggered by setting uniforms too much. This would especially appear to be a problem with the first 10 seconds of drawing.

So, rather than use a uniform to pass in material colors etc. I just hard coded constants for these colors. Performance then skyrocketed and I do not hear anymore swaps happening causing the frame skips. I guess its a specific shader versus general purpose shader issue.

The lesson is only set uniforms once at the beginning of the frame. Otherwise, you’ll be in for trouble.

[bakura]

Martinsm > Hum, okej but… how can I pass to vertex_position the right vertex coordinates ?

Furthemore, what is gl_VertexID ?

[martinsm]

Read here: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Main=49081&Number=252276
You do it same way as in OGL2.

gl_VertexID is integer index for the vertex.
You can read about it in GLSL 1.30 spec on page 58 and in GL3 spec in page 106. Read the fine manual, please

[bakura]

I had no answer on GD, but I think it’s better here so I just copy-past my message :

In the doc, it’s said that the use of gl_FragData[n] is deprecated, and to use “out” instead. But how the hell can we know in which texture data is written. Let’s take an exemple : with GLSL 1.20, when I want to write something using the FBO extension, I used to doing that :

gl_FragData[0] = myVec41;
gl_FragData[1] = myVec42;

It was easy to know that the texture bounded to unit 1 has myVec41, and that texture bounded to unit 2 has myVec42. But how can we know now with GLSL 1.30 ?

From what I’ve understood, it’s something like that :

out vec4 myVec41;
out vec4 myVec42;

void main ()
{
// Don’t use gl_FragData
}

I think that GLSL 1.30 is intelligent enough, so myVec41 will be written to the first active texture (because it is declared first), and myVec42 will be written to the second active texture (because it is declared second).

Am I right ? Furthermore, what if I want to write myVec41 in a the third active unit, and myVec42 to the fourth one ?

Thanks

[martinsm]

@bakura

But how the hell can we know in which texture data is written.

GL3.0 spec says it clearly Read section 3.12.2 Shader Outputs.

You bind output variables from fragment shader with glBindFragDataLocation before linking your program:

glBindFragDataLocation(programId, 0, "myVec41");
glBindFragDataLocation(programId, 1, "myVec42");
glLinkProgram(programId);

This means myVec41 will go to first draw buffer and myVec42 will go to second. You specifiy draw buffers with glDrawBuffers function.

[bakura]

Oh yes, this is because I only read GLSL specs… Thank you ;). I’ll read the whole OpenGL 3.0 specs too.