Miscellaneous OpenGL questions (mostly dealing with shaders)

Given that you say that you want to learn the modern approach, the answer to almost all of your questions are not relevant. In the code you posted, all functions except glBindBuffer, glUseProgram and glDrawArrays are deprecated,s o questions about them are not relevant in the context of your final goal.

• Materials and coloring has to be done by yourself in the shader, so glColor and glMaterial are all out of the question; you have to implement lighting and all that yourself in the shaders.
• Transformation has to be done by yourself and be uploaded to the shader programs as uniforms, so glPushMatrix, glRotate and all those functions are out of the question; you have to replace those with some other math library.
• Vertex arrays has been generalized and the specific functions such as glVertexPointer, glNormalPointer adn glEnableClientState has been replaced with generic attributes such as glVertexAttribArray (one generic function for any kind of vertex attribute, not a specific function for specific vertex attributes) and glEnableVertexAttribArray.

Otherwise, your buffer object and program object binding seems to be fine in relation to where you bind, where you set vertex array pointers, where you draw the arrays and so on.

Thank you! So if the functions aren't listed at http://www.opengl.org/sdk/docs/man/ then I shouldn't use them if I want to use the modern approach. Learning OpenGL ES 2.0 should be very similar because it doesn't include any of the deprecated stuff as far as I know.

One more thing, I'm guessing per-pixel lighting via fragment shading is the modern approach. How do you apply a shader to the entire screen and not just a model?

Thank you! So if the functions aren't listed at http://www.opengl.org/sdk/docs/man/ then I shouldn't use them if I want to use the modern approach. Learning OpenGL ES 2.0 should be very similar because it doesn't include any of the deprecated stuff as far as I know.

That seems to be the case, yes.

One more thing, I'm guessing per-pixel lighting via fragment shading is the modern approach.

Yes, fragment shaders are the way to do per-pixel lighting.

How do you apply a shader to the entire screen and not just a model?

That would depend on what kind of full-screen effect you want to do. You could, for example, render the scene to an off-screen texture and then draw the texture onto a full-screen quad. Use the desired fragment shader when drawing the quad.

I ask about the full-screen shader because I assumed that was how lighting was added, is that not the case?

Ignoring exotic lighting techniques, it's typically enough to do them in the fragment shader when you draw the model. You don't see any effect of the lighting anywhere except for where the model is actually drawn. You need some kind of post-processing technique only if you want, say, halos or glows around very bright spots because they spread outside the model.

Sorry, I ask that question wrong. The post-processing bit is interesting though, thank you.

I know you can apply shaders to models, and basic lighting can be done that way. Is there a way to use a shader to add lighting to every model in a scene at once? I'm having a very hard time specifying this question

Brother Bob wanted to stay away from exotic lighting techniques, but I'm feeling adventurous.

Basically, ignoring extremely exotic lighting techniques (and if anyone else feels more adventurous, go ahead), there are two main ways in which you do lighting:

1) forward shading: you render your scene model by model and do the lighting either in the vertex shader or fragment shader, depending on the effect you want to obtain and the trade between visual quality and speed.

2) deferred shading: you first render your scene in special textures that will retain different attributes per pixel, like diffuse color (before lighting), screen position (depth), normal and any other kind of attribute that you would need in your lighting calculations. After the first pass is complete (all opaque objects were rendered in these special textures), you draw a fullscreen quad with a special shader that uses all these textures to perform lighting on each pixel on the screen. This technique is a bit more tricky, but I'm assuming you're not afraid and you want to learn new and exciting stuff. Lots of new games use this, but it can be quite heavy on texture memory. Also, handing transparent objects can be quite tricky, but there are tons of books explaining all that (ShaderX 4- 7, GPU Gems, etc).

After all that, you can (and should, because it's nice) do some image post processing. In the deferred shading technique, since you have more information per pixel than just color and depth, you can get quite creative with your post processing. In forward shading, for more complex post processing you will most likely need to render the scene multiple times in multiple textures. Come to think about it. deferred shading can be considered a quite heavy post processing effect :p

I know you can apply shaders to models, and basic lighting can be done that way. Is there a way to use a shader to add lighting to every model in a scene at once? I'm having a very hard time specifying this question

If you use deferred shading (as described by LordJulian above), you are no longer on the level of individual meshes, as (often) all you have is the relevent shading data for that pixel. A common technique is to draw bounding geometry for calculating dynamic lighting so that lighting is only calculated if the light is visible and touching (or close to touching) those pixels. Deferred shading can also be useful to reduce the number and complexity of shaders due to its separation of calculating diffuse color from pretty much all of the lighting options.

2 more cents throws in:

If you use deferred shading (as described by LordJulian above)

DON'T! don't use deferred shading as described by me above, research it and use it as described by someone who actually used it; I only wanted to paint the available pictures.

Also, my advice is: use the forward shading technique, it's more forgiving. When that fails to provide the results you're looking for, add a post processing step and milk that into more and more complex filters. In no time you'll do the steps to prepare yourself for deferred shading and you won't even know it. Don't go full deferred until you are ready, deferred shading, while offering an elegant model that promises to solve lots of issues, presents lots of problems in itself. You'd have to be more controlled in the way you render your scene, with the different render targets and the way you pack/unpack information, etc. In one word, you'd have to be an obsessed management whore with your rendering pipeline(are we allowed to say whore in here? we should, it's the internets).

And, before you reach the "relevant shading data for that pixel" stage, you still have to first RENDER that data into the render targets; this is done, of course, with a custom shader that outputs all the needed values, which, later, will be interpreted by the super-shader. So, shader complexity is not really lower, it's just separated into multiple shaders, which, in itself, is a complex thing to do.

So, go gradually, and know that whatever you learn/experiment with "the classical way of applying shaders to models and basic lighting " will stay with you and will be relevant. Deferred shading is, after all, forward shading a full screen quad with some real-time generated textures :).

I couldn't disagree more. However, everything depends on what "results you're looking for". That custom shader that outputs the values does just that and often only that. Then the shaders that do lighting are completely separate. Now you have much fewer shaders as well as many more lights. Clever implementations even get more dynamic shadowing (I haven't looked at those much though).

I'd have to disagree that deferred shading is any harder than forward, especially if you've done something like shadow mapping before (ie, you've done more with OpenGL than send a single tri through a VAO). I thought you summarized deferred (in the manner that most would implement) rather succinctly, and of course more research would be needed to implement it.

The lighting shader(s) for deferred are a lot less complicated than the uber-shader or 293485 shaders for various combinations of diffuse texturing (splatting, bump, etc), shadow or not, number of lights on object, etc. Perhaps not just one, but not a "super-shader" when it has a single, easily maintainable task to perform per shader. Separable shader objects help, but I really prefer the clean split.

You'd have to be more controlled in the way you render your scene, with the different render targets and the way you pack/unpack information, etc. In one word, you'd have to be an obsessive with your rendering pipeline.

Curious, filling a few buffers with carefully chosen layouts is hardly obsessive (I apologize for the censorship, but it wasn't relevent to what I was quoting, so I just left it out). In what way to you need to be more controlled? I get needing a forward pass for transparency, but chances are there's not that much of that and you didn't need that many lighting effects from it anyway (or at least I don't which is why I don't mind needing the pass for it).

If anyone could point me in the right direction for converting my render code to the non-deprecated functions I would greatly appreciate it. Everything I try crashes the JVM. I know this is asking a lot. glVertexAttribArray is not straightforward at all.

		
                
                glBindBuffer(GL_ARRAY_BUFFER, vbos[0]); //vbos[0] is vertex buffer handle, not deprecated
		glVertexPointer(3, GL_FLOAT, 0, 0);//deprecated
		glBindBuffer(GL_ARRAY_BUFFER, vbos[1]); //vbos[1] is normal buffer handle, not deprecated
		glNormalPointer(GL_FLOAT, 0, 0);//deprecated
		
		glEnableClientState(GL_VERTEX_ARRAY);//deprecated
		glEnableClientState(GL_NORMAL_ARRAY);//deprecated
		
		glUseProgram(shaderProgram); //where should this go? It is only applied at glDrawArrays, correct?
		glDrawArrays(GL_TRIANGLES, 0, model.getFaces().size() * 3);
		
                //cleanup
                glUseProgram(0);
		glDisableClientState(GL_VERTEX_ARRAY);//deprecated
		glDisableClientState(GL_NORMAL_ARRAY);//deprecated
		glBindBuffer(GL_ARRAY_BUFFER, 0);

Thanks! Thanks for all of the great info so far as well.

The direct translation of that particular piece of code would look something like this:

// Bind the position attribute of the vertex array
glBindBuffer(GL_ARRAY_BUFFER, vbos[0]);
glVertexAttribPointer(positionLocation, 3, GL_FLOAT, GL_FALSE, 0, 0);
glEnableVertexAttribArray(positionLocation);

// Bind the normal attribute of the vertex array
glBindBuffer(GL_ARRAY_BUFFER, vbos[1]);
glVertexAttribPointer(normalLocation, 3, GL_FLOAT, GL_FALSE, 0, 0);
glEnableVertexAttribArray(normalLocation);

glUseProgram(shaderProgram);
glDrawArrays(GL_TRIANGLES, 0, model.getFaces().size() * 3);
glUseProgram(0);

glDisableVertexAttribArray(vertexLocation);
glDisableVertexAttribArray(normalLocation);

glBindBuffer(GL_ARRAY_BUFFER, 0);


But you also have to setup your shader infrastructure. You need to get the location of the position and the normal attribute so you can attach the correct attribute arrays to the correct attribute in the shader. You can use glGetAttribLocation to get the location of the index of an attribute so you can pass the location to glVertexAttribPointer and glEnableVertexAttribArray.

You also need to get a math library for matrices if you want to add the transformations from your first post.

Nevermind, thank for the help. I found someone that explained the relationship between VBOs and VAOs. I was associating VAO's with the deprecated Vertex Arrays and ignoring everything that talked about them, funny mistake.

When the model loads for the first time,

		int vaoId = glGenVertexArrays();
		glBindVertexArray(vaoId);
		
		int vboVertexHandle = glGenBuffers();
		int vboNormalHandle = glGenBuffers();
		
		glBindBuffer(GL_ARRAY_BUFFER, vboVertexHandle);
		glBufferData(GL_ARRAY_BUFFER, vertices, GL_STATIC_DRAW);
		glVertexAttribPointer(0, 3, GL_FLOAT, false, 0, 0);
		
		glBindBuffer(GL_ARRAY_BUFFER, vboNormalHandle);
		glBufferData(GL_ARRAY_BUFFER, normals, GL_STATIC_DRAW);
		glVertexAttribPointer(1, 3, GL_FLOAT, false, 0, 0);
		
		glBindBuffer(GL_ARRAY_BUFFER, 0);
		glBindVertexArray(0);
		return vaoId;

and every time it renders it runs

                glBindVertexArray(vao);
		glEnableVertexAttribArray(0);
		glEnableVertexAttribArray(1);

		glUseProgram(shaderProgram);
		glDrawArrays(GL_TRIANGLES, 0, model.getVertices().size() * 6);
		glUseProgram(0);
		glBindBuffer(GL_ARRAY_BUFFER, 0);
		glBindVertexArray(0);

It is amazing how a three letter acronym through me off. I'm having a weird issue where only one side of each model is being shaded but I'll figure it out.

Anyone have any ideas on the reason only one side of my models are getting any shading now? All I have changed is the stuff I posted in my last post. I realize that isn't much to go off of.

You haven't posted any code related to the shading, so there's no way we could point towards something wrong.

I haven't changed any of the shaders or the way the shader program is built. Could my vertex normals not be in use?

The fact that you haven't change the shaders doesn't say much, since you haven't shown the shaders yet. So without that, I could answer your question; yes, the normals could be unused. Just like pretty much anything related to shading could be wrong. Have you checked for errors: OpenGL error bits, return values, shader compilation status, program linkage status, location bindings, and all that?

No, I haven't checked any of that. LWJGL seems to handle errors pretty well, it gives pretty good feedback if it doesn't like something.

I'm using Oskar @ thecodinguniverse.com's method for creating the shader program. My only modifications are passing the filename to another method, that returns the entire contents of the text back as a string for compilation. It seems to do what it's supposed to do, I didn't see a reason to reinvent the wheel.

public static int loadShaderPair(String vertexShaderName, String fragmentShaderName) throws IOException{
		
		int shaderProgram = glCreateProgram();
		int vertexShader = glCreateShader(GL_VERTEX_SHADER);
		int fragmentShader = glCreateShader(GL_FRAGMENT_SHADER);
		
		glShaderSource(vertexShader, TextToString.convertToString("res\\shaders\\" + vertexShaderName));
		glCompileShader(vertexShader);
	      if (glGetShaderi(vertexShader, GL_COMPILE_STATUS) == GL_FALSE) {
	            System.err
	                    .println("Vertex shader wasn't able to be compiled correctly. Error log:");
	            System.err.println(glGetShaderInfoLog(vertexShader, glGetProgrami(shaderProgram, GL_INFO_LOG_LENGTH)));
	            return -1;
	        }
	      
	      glShaderSource(fragmentShader, TextToString.convertToString("res\\shaders\\" + fragmentShaderName));
	        glCompileShader(fragmentShader);
	        if (glGetShaderi(fragmentShader, GL_COMPILE_STATUS) == GL_FALSE) {
	            System.err
	                    .println("Fragment shader wasn't able to be compiled correctly. Error log:");
	            System.err.println(glGetShaderInfoLog(fragmentShader, glGetProgrami(shaderProgram, GL_INFO_LOG_LENGTH)));
	        }
	        
	        glAttachShader(shaderProgram, vertexShader);
	        glAttachShader(shaderProgram, fragmentShader);
	        glLinkProgram(shaderProgram);
	        if (glGetProgrami(shaderProgram, GL_LINK_STATUS) == GL_FALSE) {
	            System.err.println("Shader program wasn't linked correctly.");
	            System.err.println(glGetProgramInfoLog(shaderProgram, 1024));
	            return -1;
	        }
	        glDeleteShader(vertexShader);
	        glDeleteShader(fragmentShader);
	        return shaderProgram;
	      
	}

I'm also using his simple "pixel_phong_lighting" shaders. I have the OpenGL 4.0 Shading Language Cookbook" coming in a few days, until then I'm just using what I know will work. I'm also still using the built in matrix functions, coloring and shininess. My next step after I get this back to functioning how it should, is using my own matrix system.

Fragment Shader:

/*
 * Copyright (c) 2012, Oskar Veerhoek
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 * list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright notice,
 * this list of conditions and the following disclaimer in the documentation
 * and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
 * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
 * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
 * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 * The views and conclusions contained in the software and documentation are those
 * of the authors and should not be interpreted as representing official policies,
 * either expressed or implied, of the FreeBSD Project.
 */

#version 120

// The colour that we passed in through the vertex shader.
varying vec4 varyingColour;
// The normal that we passed in through the vertex shader.
varying vec3 varyingNormal;
// The vertex that we passed in through the vertex shader.
varying vec4 varyingVertex;

void main() {
    vec3 vertexPosition = (gl_ModelViewMatrix * varyingVertex).xyz;
    vec3 surfaceNormal = normalize((gl_NormalMatrix * varyingNormal).xyz);
    vec3 lightDirection = normalize(gl_LightSource[0].position.xyz - vertexPosition);
    float diffuseLightIntensity = max(0, dot(surfaceNormal, lightDirection));
    gl_FragColor.rgb = diffuseLightIntensity * varyingColour.rgb;
    gl_FragColor += gl_LightModel.ambient;
    vec3 reflectionDirection = normalize(reflect(-lightDirection, surfaceNormal));
    float specular = max(0.0, dot(surfaceNormal, reflectionDirection));
    if (diffuseLightIntensity != 0) {
        float fspecular = pow(specular, gl_FrontMaterial.shininess);
        gl_FragColor += fspecular;
    }
}

Vertex Shader:

/*
 * Copyright (c) 2012, Oskar Veerhoek
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 * list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright notice,
 * this list of conditions and the following disclaimer in the documentation
 * and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
 * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
 * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
 * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 * The views and conclusions contained in the software and documentation are those
 * of the authors and should not be interpreted as representing official policies,
 * either expressed or implied, of the FreeBSD Project.
 */

#version 120

// The colour we're going to pass to the fragment shader.
varying vec4 varyingColour;
// The normal we're going to pass to the fragment shader.
varying vec3 varyingNormal;
// The vertex we're going to pass to the fragment shader.
varying vec4 varyingVertex;

void main() {
    // Pass the vertex colour attribute to the fragment shader.
    // This value will be interpolated automatically by OpenGL
    // if GL_SHADE_MODEL is GL_SMOOTH. (that's the default)
    varyingColour = gl_Color;
    // Pass the vertex normal attribute to the fragment shader.
    // This value will be interpolated automatically by OpenGL
    // if GL_SHADE_MODEL is GL_SMOOTH. (that's the default)
    varyingNormal = gl_Normal;
    // Pass the vertex position attribute to the fragment shader.
    // This value will be interpolated automatically by OpenGL
    // if GL_SHADE_MODEL is GL_SMOOTH. (that's the default)
    varyingVertex = gl_Vertex;
    // Send the vertex position, modified by glTranslate/glRotate/glScale
    // and glOrtho/glFrustum/gluPerspective to primitive assembly.
    gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}

and finally, my full render method

	public void render() {
		glPushMatrix();// deprecated
		glRotatef(rotation, rx, ry, rz);// deprecated
		glTranslatef(x, y, z);// deprecated
		glScalef(sx, sy, sz);// deprecated
		
		glBindVertexArray(vao);
		glEnableVertexAttribArray(0);
		glEnableVertexAttribArray(1);
		glMaterialf(GL_FRONT_AND_BACK, GL_SHININESS, 10f); //deprecated
		glColor4f(1f, 0f,0f,1f);//deprecated
		glUseProgram(shaderProgram);
		glDrawArrays(GL_TRIANGLES, 0, model.getFaces().size() * 9);
		glUseProgram(0);
		
		glBindVertexArray(0);
		glDisableVertexAttribArray(0);
		glDisableVertexAttribArray(1);
		glPopMatrix();// deprecated
	}

And finally, some screenshots