Newbie Texture mapping help

Hi there,
I have recently started to play with glsl in linux.
Now I have a question for the glsl learned guys about texturing mapping.

How does gl_TexCoord0 exactly works? I am trying to map a rectangular texture to rectangular geometry.
I know in the regular Open GL app we specify texture
co-ordinate for each vertices. How do we do that in the glsl?

I have looked at the code in www.clockworkcoder.org the texture mapping tutorial. Couldn’t understand much? Can someone be kind enough to take their time and enlighten me?
Thanks.

Here is a snippet of my code from vertex shader:

gl_TexCoord[0] = gl_MultiTexCoord0;

And fragment Shader:

uniform sampler2DRect testTexture;
void main (void)

{

gl_FragColor = texture2DRect(testTexture, vec2(gl_TexCoord[0]));

}

Its the same thing really. You still call glTexCoord before each vertex to specify it’s texture coordinate. That’s where gl_MultiTexCoord0 gets it’s values from. Use glMultiTextCoord() if you need to set gl_MultiTexCoord[1-7] (you can use this function to set 0 too infact).

Hope that helps.

Got it! Thanks. :slight_smile: :slight_smile:

If you’re just using gl_TexCoord[0] to index into a texture, you can also use your own varying vec2 instead of the built in varying which is an array of vec4 floats. See the below code snippet:

//vertex shader
varying vec2 textureCoord;
void main(void)
{
textureCoord = gl_MultiTexCoord0.xy;
gl_Position = ftransform();
} 
//fragment shader
uniform sampler2DRect testTexture;
varying vec2 textureCoord;
void main(void)
{
gl_FragColor = texture2DRect(testTexture, textureCoord);
} 

This is cleaner, there is no need to pass a vec4 when you are only using 2 components of it.

I’m really hoping we wont need to do that as the compilers become more advanced. The strict type checking should make it easy to see only the first two components of gl_TexCoord[0] are being used…

I’m really hoping we wont need to do that as the compilers become more advanced.
No. Never. And not because of bad compilers.

If I create a 4 element array of floats in C++, I get exactly that. The fact that I might use only one or two elemenets of that array doesn’t change the fact that I told the language that I wanted 4 elements. Obviously, if I never use it, it doesn’t need to exist. But if I do use it, it should exist exactly as I asked for it.

If you ask for a vec4, you get a vec4. End of story. The compiler should not be trying to determine if the user really meant a vec4 or if they were lazy and wanted something else.

This is cleaner, there is no need to pass a vec4 when you are only using 2 components of it.
kingjosh, are you sure of this ? gl_TexCoord is a build in variable and is passed anyway to fragment shader, am I wrong ?

wizzo

kingjosh, are you sure of this ? gl_TexCoord is a build in variable and is passed anyway to fragment shader, am I wrong
gl_TexCoord, even though its built in, still uses up (your limited number) varying variables unfortuatly.

yeah that’s what I thought.

Is it the same with gl_Light[] ? I mean, if you have no glEnable(GL_LIGHTi) in your code, are the gl_LightSourceParameters[NB_SUPPORTED_LIGHTS] passed anyway ?

  [quote]This is cleaner, there is no need to pass a vec4 when you are only using 2 components of it. 

kingjosh, are you sure of this ? gl_TexCoord is a build in variable and is passed anyway to fragment shader, am I wrong ?

wizzo [/QUOTE]wizzo - if you don’t set gl_TexCoord in the vertex shader it is not passed to the fragment shader. If you use gl_TexCoord[0] in your fragment shader without setting it in your vertex shader, you should get an error.

Is it the same with gl_Light ? I mean, if you have no glEnable(GL_LIGHTi) in your code, are the gl_LightSourceParameters[NB_SUPPORTED_LIGHTS] passed anyway ?
It is irrelevant whether or not glEnable(GL_LIGHTi) is contained within your fixed function OpenGL code, you can still access the built in uniforms pertaining to lighting and you should receive the default values in your shader. These should only consume a uniform if used in your shaders.

 [quote]kingjosh, are you sure of this ? gl_TexCoord is a build in variable and is passed anyway to fragment shader, am I wrong

gl_TexCoord, even though its built in, still uses up (your limited number) varying variables unfortuatly. [/QUOTE]Correct, if used gl_TexCoord does use slots as a varying variable. If you’re indexing into a two dimensional texture, and only using the s and t components of gl_TexCoord then you should define your own vec2 varying in order to preserve the number of varying variables.

ok, thanks for clearing things up kingjosh.

Originally posted by Korval:
[b] [quote]I’m really hoping we wont need to do that as the compilers become more advanced.
No. Never. And not because of bad compilers.

If I create a 4 element array of floats in C++, I get exactly that. The fact that I might use only one or two elemenets of that array doesn’t change the fact that I told the language that I wanted 4 elements. Obviously, if I never use it, it doesn’t need to exist. But if I do use it, it should exist exactly as I asked for it.

If you ask for a vec4, you get a vec4. End of story. The compiler should not be trying to determine if the user really meant a vec4 or if they were lazy and wanted something else.[/b][/QUOTE]I have to disagree with you here. The difference between C++ and GLSL is that it is extreamly hard if not imposible for a C++ compiler to guarantee that you are only going to use the first two floats of the float[4] array you declared. There are so many ways that the memory can get changed.

GLSL on the other hand can very easily guarantee this. The code is small and we dont have to worry about what some other library is going to do to our memory. The strict type checking almost makes it trivial. If I only write to and reference gl_TexCoord0.xy, I dont see any reason why the compiler can't take advantage of this. This is no different then expecting the compiler to reuse TEMP varaibles when appropriate (in the ARB assembly). Just because I declare 4 temporary vec4s in my code it doesn't mean the compiler should be dumb and always allocate 4 TEMPs when I clearly am finished with the first one long before I need the 4th one. This is probably the most basic feature of an optimizing compiler. (basic as in easy, not core. The core feature is probably the code reorganization for better pipelining?)

Being able to use the built gl_TexCoord* varyings helps readability and coding speed. I never asked for gl_TexCoord0 to be a vec4, but I want to use that variable since the name is standardized. I'll be very disapointed if I am forced to always declare my own varyings to get the best performance and never use any of the built in ones.

GLSL is a language with strict type checking, C++ is not. If the compilers arn't going to take advantage of the strict type checking to optimize, then we shouldn't have been burdened with it. 

My 2 cents.

Being able to use the built gl_TexCoord* varyings helps readability and coding speed. I never asked for gl_TexCoord0 to be a vec4, but I want to use that variable since the name is standardized. I’ll be very disapointed if I am forced to always declare my own varyings to get the best performance and never use any of the built in ones.
The gl_XXXXX varyings and uniforms are provided as a way to interface with elements of the fixed function pipeline. If you’re providing both the vertex and fragment shader, there is no advantage to use the built varying gl_TexCoord. Your code would be no less readable with a varying variable with the name texCoord, in fact since you are defining the varying in the vertex shader, the gl_ would be less readable as one would assume you are using the fixed function pipeline.

If you are only using a fragment shader and using fixed function for the vertex side, then you will have to use gl_TexCoord as it’s intended to interface with fixed function.

While I don’t agree that people would assume I was using fixed-pipe for one of vertex/pixel shading if I use gl_TexCoord, I will concede that it makes the code only slightly harder to read. I still think its worse because you need to check what ‘texCoord’ is. Is it a varying, uniform or just a variable? With gl_TexCoord you know exactly what it is right away. Wanting to use gl_TexCoord to pass a texture coordinate is no different then using gl_FrontColor/gl_BackColor -> gl_Color to pass the color around.

Either way this point I made can be considered trival.

I’m more interested in being proven wrong on the main point about the optimizations.

GLSL on the other hand can very easily guarantee this.
you seem to be implying that this would be free. i imagine a good deal of complexity would need to be added to the semantic analysis phase, and probably a good chunk of time to boot. and what about issues that might come up later as shader complexity grows? i wouldn’t count on an optimization standard in any case, not ever.

i don’t see the need for this kind of thing. what’s all the fuss about?

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.