When there is no version specified in the first line of a GLSL shader (so nothing like "#version 330", which version is actually used?
Is it vendor (or even driver) specific?
What is the default GLSL version?
Assume the default version is 1.10
Note that the #version directive always must be on the first line
The #version directive must appear before anything else in a shader, save for whitespace and comments. If a #version directive does not appear at the top, then it assumes 1.10, which is almost certainly not what you want.
– OpenGL Wiki
If it's in relation to combining sources, then you could leave out the #version directive and do something like this:
const GLsizei stringCount = 2;
const GLchar *strings[stringCount] = {
"#version 330 core\n",
shaderSource,
};
glShaderSource(shader, stringCount, strings, NULL);
Related
I'm doing my first steps with OpenGL and stumbled upon a problem in my vertex shader program:
#version 330 core
layout (location = 0) in vec3 aPos;
uniform mat4 inputTransform;
void main()
{
gl_Position = inputTransform * vec4(aPos, 1.0);
}
compiles and works well, but when I change the first line to
#version 130 core
because I'm bound to use OpenGL 3.0 at max, it first complains about the "location" statement. When I remove it, the remaining error message for the line
layout in vec3 aPos;
is
ERROR: 0:2: 'in' : syntax error syntax error
What's wrong here - how do I have to declare input variables in this version of the language?
Input layout qualifiers have been added in GLSL version 1.50 wich corresponds to OpeneGL version 3.2
See OpenGL Shading Language 1.50 Specification; - 4.3.8.1 Input Layout Qualifiers; page 37.
An input layout qualifier consists of the keyword layout followed by the layout-qualifier-id-list.
It is not sufficient to remove the layout-qualifier-id-list alone, you have to remove the keyword layout too:
in vec3 aPos;
The syntax error is caused by the fact, that it is not a proper syntax, that layout is directly followed by in.
Either you have to ask for the attribute index by glGetAttribLocation after the program is linked, or you have to specify the attribute location by glBindAttribLocation before the shader program is linked.
There seems to be a lot of ambiguity about gl_FragColor being deprecated. For example, it is missing in the GLSL 4.40 specification, but it is included in the GLSL 4.60 specification.
What is the safest, most compatible, most supported strategy? Using gl_FragColor or defining a shader output like out vec4 color?
Yes, gl_FragColor is deprecated. You should use the following syntax:
layout(location = 0) out vec4 diffuseColor;
It is included in the GLSL 4.60 spec under the section 7.1.7. Compatibility Profile Built-In Language Variables. That means, if you create a core context this variable will not be available.
If you would read the the GLSL 4.40 specification carefully, then you would find gl_FragCoord in chapter "7.1.1 Compatibility Profile Built-In Language Variables", as it is in the GLSL 4.60 specification.
The following fragment output variables are available in a fragment shader when using the compatibility profile:
out vec4 gl_FragColor;
out vec4 gl_FragData[gl_MaxDrawBuffers];
Writing to gl_FragColor specifies the fragment color that will be used by the subsequent fixed functionality pipeline. If subsequent fixed functionality consumes fragment color and an execution of the fragment shader executable does not write a value to gl_FragColor then the fragment color consumed is undefined.
This means you can't use gl_FragColor, in an OpenGL Core profile Context, because it is deprecated, but it would still be available in a compatibility profile.
The modern way of writing to the output buffers from a fragment shader, is to declare user-defined output variables and to use Layout Qualifiers.
I started picking up OpenGL by using http://www.opengl-tutorial.org.
It uses following code to load and compile shaders (Linked because code is too long for this post and I think it's something with my shaders)
When running this code, it prints out "ERROR: Compiled Vertex Shader is corrupt" and "ERROR: Compiled Fragment Shader is corrupt". My shaders are following
Vertex Shader
#version 330 core
out vec3 color;
void main(){
color = vec3(1,0,0);
}
Fragment shader
#version 330
layout (location = 0) in vec3 position;
void main()
{
gl_Position.xyz = position;
gl_Position.w = 1.0;
}
I'm using XCode 5.1.1 , OpenGL 3.3 and GLSL 3.30.
It would be awesome if you guys could help me past this point. I got stuck on a YouTube tutorial that didn't use VAO's, so I went to learn these things myself so I could write the tutorial in my own code.
Thanks in advance
This is a common problem that shows up with XCode and is usually caused by text encoding or improperly null-terminated strings. There could be non-printing characters at the end of both of them.
You can look through the VertexShaderCode and FragmentShaderCode strings in a debugger and find out if there are any erroneous chars or if they're not null-terminated.
I found people running into the same errors here and here.
To fix them, open your GLSL files with text edit, text mate, or sublime text (some really basic text editor) and convert them to text only and save them as new files.
I am trying to get UBOs working, however I get a compilation error in the fragment shader:
ERROR 0:5:"(": synrax error.
Fragment Shader:
layout(std140) uniform Colors
{
vec3 SCol;
vec3 WCol;
float DCool;
float DWarm;
}colors;
Where am I going wrong?
At the begining of your fragment shader source file (the very first line) put this:
#version 140
This means that you are telling the GLSL compiler that you use the version 1.40 of the shading language (you can, of course, use a higher version - see Wikipedia for details).
Alternatively, if your OpenGL driver (and/or hardware) doesn't support GLSL 1.40 fully (which is part of OpenGL 3.1), but only GLSL 1.30 (OpenGL 3.0), you can try the following:
#version 130
#extension GL_ARB_uniform_buffer_object : require
However, this one will work only if your OpenGL 3.0 driver supports the GL_ARB_uniform_buffer_object extension.
Hope this helps.
For clarity, I start with my question:
Is it possible to use (in the shader code) the custom attribute name which I set for the TEXCOORD usage in the (OpenGL) stream mapping in RenderMonkey 1.82 or do I have to use gl_MultiTexCoord0?
(The question might be valid for the NORMAL usage too, i.e custom name or gl_Normal)
Background:
Using RenderMonkey version 1.82.
I have successfully used the stream mapping to map the general vertex attribute "position" (and maybe "normal"), but the texture coordinates does not seem to be forwarded correctly.
For the shader code, I use #version 330 and the "in" qualifier in GLSL, which should be OK since RM does not compile the shaders itself (the OpenGL driver do).
I have tried both .obj and .3ds files (exported from blender), and when checking the wavefront .obj-file, all texture coordinate information is there, as well as the vertex positions and normals.
If it is not possible, the stream mapping is broken and there is no point in naming the variables in the stream mapping editor (besides for the vertex position stream, which works), since one has to use the built-in variables anyway.
Update:
If using the deprecated built-in variables, one has to use compatibility mode in the shader e.g
#version 330 compatibility
out vec2 vTexCoord;
and, in the main function:
vTexCoord = vec2(gl_MultiTexCoord0);
(Now I'm not sure about the stream mapping of normals either. As soon as I got the texture coordinates working, I had normal problems and had to revert to gl_Normal.)
Here is a picture of a working solution, but with built-in variables (and yes, the commented texcoord variable in the picture does not have the same name as in the stream mapping dialog, but it had the same name when I tried to use it, so it's OK.):
You could try to use the generic vertices's attributes, see http://open.gl, it's a great tutorial ;)
(but I think it imply you'd have to rewrite the code to manual handle the transformations...)
#version 330
layout(location = 0) in vec3 bla_bla_bla_Vertex;
layout(location = 2) in vec3 bla_bla_bla_Normal;
layout(location = 8) in vec3 bla_bla_bla_TexCoord0;
This is a working solution for RM 1.82