I’ve been reading up on GLSL lately. To use a texture, you have to put something like “uniform sampler2D mytex” in your shader, and you have to make a couple extra calls in your application to glGetUniformLocataion and glUniform.
In arb_fp you could simply access “texture[0]” so in GLSL I expected to be able to write a line such as “uniform sampler2D mytex = gl_Texture[0]” but this doesn’t appear to be possible.
In other words, I can’t find any built in variables for accessing textures. Since textures are already bound to texture units defined by integers in the application, I don’t understand the need for the extra OpenGL calls in the application. But I’m guessing there’s a good reason for this that I just don’t see. Can anyone explain it?
Is possible that in future GLSL spec releases, texture objects will be bound to the shaders, rather than texture units, so gl_Texture[0] will be invalid.
One of the core ideas of GLSL is the separation of the shader from the main application, and trying to loosen the connection, especially when it comes to fixed indices. This allows programs to be much more supportive and flexible about supporting different shaders.
Therefore the fixed binding of textures to specific texture units doesn’t really make sense. It’s much more flexible for a shader to say “I need a texture for normals”, and the application asking “Hey shader, you need normals? OK? Here you go!” than just hoping the app knows that normals for this shader have to be in texture unit 2 (and 3 for the other and 1 for the next…).
Yes, it’s more tedious to start with, but once you have a couple basic tools to handle this, it’s much nicer not having to remember to change the app whenever you change the shader.
And more generally speaking, I think it would be nice if most of GLSL predefined variables could diseappear, like
gl_Color
gl_SecondaryColor
gl_Normal
gl_MultiTexCoordX
etc…
so that we could replace them manually, glsl style, avoiding redondancy and leaving the old OpenGL functions behind us.