
GLSL
Posted Saturday, 11 February, 2012 - 17:30 by HermanssoN inHello, I have some questions abot GLSL,
I wrote a small shader that will handle diffuse textures:
#version 150 //precision highp float; uniform mat4 proj; uniform mat4 view; uniform mat4 world; //These work layout (location = 0)in vec3 inPosition; layout (location = 1)in vec3 inNormal; layout (location = 2)in vec2 inTexCoord; out vec4 vertexPos; out vec3 normal; out vec2 texCoord; void main() { //forced to use gl_Position and gl_TexCoord[0] gl_Position = proj * view * world * vec4(inPosition,1.0); gl_TexCoord[0].st = inTexCoord; //these wont work?? No compile errors tough, I commented gl_Position and gl_TexCoord at first vertexPos = proj * view * world * vec4(inPosition,1.0); normal = inNormal; texCoord = inTexCoord; }
and
#version 150 //precision highp float; uniform sampler2D difuseMap; //Not used right nowm tried to use inTexCoord but it did not work in vec4 inVertexPos; in vec2 inTexCoord; in vec3 inNormal; //out keyword works here! out vec4 outColor; void main(void) { //must use gl_TexCoord[0] here, why? inTexCoord just reult in wierd flickering outColor = texture2D( difuseMap, gl_TexCoord[0].st ); }
I'm using Open gl 3.3 through the glControll.
The code i posted works, but as my comments show, I'm forced to use gl_TexCoord and gl_ gl_Position .
My question is why?
I would like to use only my attributes marked as in and out.
Has this to do with the version of glsl?


Comments
Re: GLSL
Fist of all, "it did not work" in the comment is not a very precise description of your problem. What do you experience? Black screen, random colors, application crash, ...?
gl_Position is a keyword that has not much to do with your attributes. You always specify gl_Position as the homogenous vertex position for the rasterizer.
You only pass the vertex position (transformed to image space or in world space, as needed) as additional attribute to the fragment shader if you need it for calculations, e.g. for lighting. This attribute has nothing to do with the actual fragment position, however, which is solely dependent on gl_Position. So, technically - though this would lead to wrong shading results - you could set the gl_Position to the real position in the vertex shader and pass another position to the fragment shader for shading calculations.
What OpenGL profile are you using? The core profile of OpenGL 3.3 forbids deprecated shader variables (an overview over the variables can be found here: www.khronos.org/files/opengl-quick-reference-card.pdf), so gl_TexCoord is not present anymore and an assignment to it could/should lead to an error.
So, your normal and texture coordinate should be passed with out and in attributes as you already did, but your position is set in the vertex shader with
gl_Position = proj * view * world * vec4(inPosition,1.0);.A second thing is your attribute locations. I am unfamiliar with the "layout (location = 0)" practise. Can you confirm with easy debugging output that this works? Usually, you would query the attribute location from your application by its name, e.g.
GL.GetAttribLocation(shaderHandle, "inPosition");. This adds more flexibility to the application as you do not have to change/remember preset locations.Re: GLSL
Hi.
When I Create my VAO i use:
I tried to use:
instead of :
Instead of my mesh I got a small round cluster of triangles , so layout (location = 0) seems to make sure that the data is placed correctly.
I tried using GL.GetAttribLocation and got:
I tried out my code using a normal GameWindow that i set to use open gl 3.3 :
about the layout (location = 0):
"With this syntax, you can forgo the use of glBindAttribLocation entirely. If you try to combine the two and they conflict, the layout qualifier always wins. "
from: http://www.opengl.org/wiki/GLSL_Type_Qualifiers
Re: GLSL
When I Create my VAO i use:
Please note that there is a difference between generic vertex attribute arrays and Vertex Array Objects (VAO). The latter is just a state object that collects bindings of Vertex Buffer Objects such that you can bind everything in just a single call when drawing. What you use are just regular vertex attribute arrays.
Instead of my mesh I got a small round cluster of triangles , so layout (location = 0) seems to make sure that the data is placed correctly.
This should not happen if everything is set up correctly. When calling shader attributes by their name only, you have to do this everywhere you access them in your application instead of using explicit indices as you leave indexing to OpenGL.
GL.GetAttribLocation(shader.Program, "inNormal"); // = -1
This indicates that there's an error somewhere in your application. Make sure that "inNormal" is used in your shader, not just defined. If you do not use it or if you only calculate things with it which are not handed over to the fragment shader, the shader compiler will optimize away the whole variable.
OpenTK.Graphics.GraphicsContextFlags.ForwardCompatibleAre your video drivers up to date? As far as I know, your application should not work correctly as long as you are using a forward-compatible OpenGL context. The flag for forward-compatibility removes all deprecated calls and should prevent to use them, including the usage of gl_TexCoord in your shader.
Re: GLSL [ Solved]
Hi.
I managed to resolve the errors, my cod now looks like this:
OpenGL
vertex shader :
Fragment shader:
this time around i changed my names so i had unique names for incoming texCoords.
If both vertex shader and fragment shader had the variable:
in vec2 texCoord;I got wierd results. Note that I removed
inNormalfrom the fragment shader, I belive that's why the positions got the wrong data.If I send my normals to the position slot the result will look like a small ball of messed up triangles :)
So the lesson I learned from this is to be careful with variable names inside the shader, same names in both fragment and vertex shader will not give an error, just bad results.
Thank you for your help!