Last Ray of Hope » OpenGL

OpenGL Shader Debugging

Kaluriel — Fri, 28 Oct 2011 21:17:50 +0000

One thing that always annoys me with using glGetShaderInfoLog(), is that when compiling OpenGL shaders multiple sources can be used. Because of this, the line numbers get shifted, and trying to find line 123 where a syntax error exists is a length process.

So I made a function that will take the sources list and output the lines with line numbers.

Source code

void OutputWithLineNumbers( const char ** inSources, const unsigned int inCount )
{
	bool unendedLineNo = false;
	int lineNumber = 1;
 
	for( unsigned int i = 0; i < inCount; ++i )
	{
		const char * cur = inSources[i];
		const char * next = NULL;
 
		do
		{
			//
			if( !unendedLineNo )
			{
				printf( "%04d: ", lineNumber );
			}
 
			//
			next = strchr( cur, '\r' );
 
			//
			if( next )
			{
				size_t len = ( next - cur );
				char * lineText = (char *)alloca( len );
				memcpy( lineText, cur, len );
				lineText[len] = 0;
 
				printf( "%s\n", lineText );
 
				unendedLineNo = false;
				++lineNumber;
			}
			else
			{
				printf( "%s", cur );
				unendedLineNo = true;
			}
 
			//
			cur = next + 2;
		} while( next );
	}
 
	if( unendedLineNo )
	{
		printf( "\n" );
	}
}

This code requires the source files to have a carriage return as well as a new line character.

iOS: Using Separate Shaders

Kaluriel — Thu, 18 Aug 2011 20:22:37 +0000

One of the lovely additions to iOS5 is there is now the ability to use separate vertex and fragment shaders (GL_EXT_separate_shader_objects).

The first step in using separate shaders is to create an object to bind them onto that will be our overall shader program, known as a pipeline object.

Source code

GLuint gProgramPipeline = 0;
GLuint gVertexProgram = 0;
GLuint gFragmentProgram = 0;
 
//
//
int main()
{
	//
	CreatePipeline();
	CreateShaders();
 
	//
	BindShadersToPipeline();
 
	//
	do
	{
		//
		UpdateUniforms();
 
		//
		BindPipeline();
		DrawSomething();
		UnbindPipeline();
	}
	while( true );
 
	//
	DestroyShaders();
	DestroyPipeline();
}
 
//
//
void CreatePipeline()
{
	glGenProgramPipelinesEXT( 1, &gProgramPipeline );
}
 
//
//
void DestroyPipeline()
{
	if( gProgramPipeline )
	{
		glDeleteProgramPipelinesEXT( 1, &gProgramPipeline );
		gProgramPipeline = 0;
	}
}

This pipeline object acts similar to vertex array object (VAO) only with shader programs, however instead of using glUseProgram, a separate function glUseProgramStagesEXT() must be used to bind the shader program to the pipeline, specifying the role of the shader program.

Source code

//
//
void BindShadersToPipeline()
{
	glUseProgramStagesEXT( gProgramPipeline, GL_VERTEX_SHADER_BIT_EXT, gVertexProgram );
	glUseProgramStagesEXT( gProgramPipeline, GL_FRAGMENT_SHADER_BIT_EXT, gFragmentProgram );
}

Updating uniforms is slightly different as well.

Source code

//
//
void UpdateUniforms()
{
	//
	GLint uniformLoc = glGetUniformLocation( gVertexProgram, "myVertUniform" );
	glProgramUniform1fEXT( gVertexProgram,
			       uniformLoc,
			       1.248f );
 
	uniformLoc = glGetUniformLocation( gFragmentProgram, "myFragUniform" );
	glProgramUniform1fEXT( gFragmentProgram,
			       uniformLoc,
			       6.1218f );
 
	//
	uniformLoc = glGetUniformLocation( gVertexProgram, "myCommonUniform" );
	float commonValue = 2.0f;
 
	glProgramUniform1fEXT( gVertexProgram,
			       uniformLoc,
			       commonValue );
 
	uniformLoc = glGetUniformLocation( gFragmentProgram, "myCommonUniform" );
	glProgramUniform1fEXT( gVertexProgram,
			       uniformLoc,
			       commonValue );
}

Finally to use the program pipeline, we just need to bind it.

Source code

//
//
void BindPipeline()
{
	glBindProgramPipelineEXT( gProgramPipeline );
}
 
//
//
void UnbindPipeline()
{
	glBindProgramPipelineEXT( 0 );
}

fef

Using Vertex Array Objects

Kaluriel — Sat, 30 Jul 2011 12:10:32 +0000

Amy Pond <3

With my recent post about what iOS devices supported what extensions, I noticed a lot of people got to my website trying to work out how to use Vertex Array Objects (VAO) with the GL_OES_vertex_array_object extension.

They're easy to use so I thought I would write up a quick how-to use them. There is a limitation with the VAO however, it cannot be shared between contexts and can be problematic for multithreading.

If you plan to use one, either generate and create for each context you will be using it on. Or generate and create on the context you will be mostly using it on. It might be a mistake, since it says they didn't want to create the first non-shared named object in OpenGL ES, however at the same time they say no to sharing.

Like with any OpenGL object, first a name must be generated for the object, make sure you always initialise your name variables to 0, since this refers to a non-object.

Source code

GLuint gVAO = 0;
 
//
//
int main()
{
	//
	GenerateVAO();
	CreateVAO();
 
	//
	do
	{
		BindVAO();
		DrawSomething();
		UnbindVAO();
	}
	while( 1 );
 
	//
	DestroyVAO();
}
 
//
//
void GenerateVAO()
{
	// Generate Name for VAO
	glGenVertexArraysOES( 1, &gVAO );
}
 
//
//
void DestroyVAO()
{
	if( gVAO )
	{
		glDeleteVertexArraysOES( 1, &gVAO );
		gVAO = 0;
	}
}

I've also put the syntax in there for deleting the VAO when you do not need it anymore.

Now for filling in the VAO. The VAO is basically a block of memory for storing vertex data schematic. For fixed function, the schematic includes information about data type, count, stride, buffer offset and whether it is enabled. This is for every pointer, glVertexPointer, glNormalPointer, glColorPointer, glTexCoordPointer, etc.

And for the shader program pipeline, it contains the schematic for each glVertexAttribPointer.

Source code

//
//
void CreateVAO()
{
	// Bind VAO
	glBindVertexArrayOES( gVAO );
 
	// Bind Vertex Buffer
	glBindBuffer( GL_ARRAY_BUFFER, gSomeVBO );
 
	// Fill in the VAO with our vertex schematic
	if( hasShaders )
	{
		glEnableVertexAttribArray( 0 );
 
		glVertexAttribPointer( 0,			// Attribute bind location
				       3,			// Data type count
				       GL_FLOAT,		// Data type
				       GL_FALSE,		// Normalise this data types?
				       sizeof(float) * 3,	// Stride to the next vertex
				       0 );			// Vertex Buffer starting offset
	}
	else
	{
		glEnableClientState( GL_VERTEX_ARRAY );
 
		glVertexPointer( 3,			// Data type count
				 GL_FLOAT,		// Data type
				 sizeof(float) * 3,	// Stride to the next vertex
				 0 );			// Vertex Buffer starting offset
	}
 
	// Unbind VAO
	glBindVertexArrayOES( 0 );
}

You'll notice that when I am finished with with the VAO, I unbind it. This is because any changes to the vertex pointers will override any we have set within this function, so to protect the VAO we have just filled in, we unbind it.

When using a VAO, you will not need to bind the GL_ARRAY_BUFFER again the next time you use the VAO, since whenever you make a call to gl*Pointer() or glVertexAttribPointer(), the vertex buffer is stored with the vertex schematic. Because of this, you can have multiple streams of data from different vertex buffers.

Source code

//
//
void CreateVAO()
{
	// Bind VAO
	glBindVertexArrayOES( gVAO );
 
	// Vertex Buffer 1
	{
		// Bind Vertex Buffer
		glBindBuffer( GL_ARRAY_BUFFER, gSomeVBO1 );
 
		// Fill in the VAO with our vertex schematic
		if( hasShaders )
		{
			//
			glEnableVertexAttribArray( 0 );
 
			glVertexAttribPointer( 0,			// Attribute bind location
					       3,			// Data type count
					       GL_FLOAT,		// Data type
					       GL_FALSE,		// Normalise this data types?
					       sizeof(float) * 5,	// Stride to the next vertex
					       0 );			// Vertex Buffer starting offset
 
			//
			glEnableVertexAttribArray( 1 );
 
			glVertexAttribPointer( 1,			// Attribute bind location
					       2,			// Data type count
					       GL_FLOAT,		// Data type
					       GL_FALSE,		// Normalise this data types?
					       sizeof(float) * 5,	// Stride to the next vertex
					       sizeof(float) * 3 );	// Vertex Buffer starting offset
		}
		else
		{
			//
			glEnableClientState( GL_VERTEX_ARRAY );
 
			glVertexPointer( 3,			// Data type count
					 GL_FLOAT,		// Data type
					 sizeof(float) * 5,	// Stride to the next vertex
					 0 );			// Vertex Buffer starting offset
 
			//
			glClientActiveTexture( GL_TEXTURE0 );
			glEnableClientState( GL_TEXTURE_COORD_ARRAY );
 
			glTexCoordPointer( 2,						// Data type count
					   GL_FLOAT,					// Data type
					   sizeof(float) * 5,				// Stride to the next vertex
					   (const GLvoid *)(sizeof(float) * 3) );	// Vertex Buffer starting offset
		}
	}
 
	// Vertex Buffer 2
	{
		// Bind Vertex Buffer
		glBindBuffer( GL_ARRAY_BUFFER, gSomeVBO2 );
 
		// Fill in the VAO with our vertex schematic
		if( hasShaders )
		{
			glEnableVertexAttribArray( 2 );
 
			glVertexAttribPointer( 2,			// Attribute bind location
					       2,			// Data type count
					       GL_FLOAT,		// Data type
					       GL_FALSE,		// Normalise this data types?
					       sizeof(float) * 2,	// Stride to the next vertex
					       0 );			// Vertex Buffer starting offset
		}
		else
		{
			glClientActiveTexture( GL_TEXTURE1 );
			glEnableClientState( GL_TEXTURE_COORD_ARRAY );
 
			glTexCoordPointer( 2,			// Data type count
					   GL_FLOAT,		// Data type
					   sizeof(float) * 2,	// Stride to the next vertex
					   0 );			// Vertex Buffer starting offset
		}
	}
 
	// Unbind VAO
	glBindVertexArrayOES( 0 );
}

In the code above, the first texture coordinate set is interlaced with the position data (offset by the sizeof three floats), and is bound using the first vertex buffer (gSomeVBO1). But the second texture coordinate is contained within a second vertex buffer (gSomeVBO2).

Finally, using the VAO is easy.

Source code

//
//
void BindVAO()
{
	glBindVertexArrayOES( gVAO );
}
 
//
//
void UnbindVAO()
{
	glBindVertexArrayOES( 0 );
}

The call to glBindVertexArrayOES() with the VAO object name is just like calling everything we did in the create function. The only limitation is that one VAO is needed per vertex buffer, even if you have the same vertex schematic.

However, this is a great place for optimisation by sharing the same vertex buffer for vertex data with the same schematic. Then whenever you make a call to glDrawArrays() you can specify which vertex to start from. glDrawElements() is a little more complicated, you will need to increase all your elements in your index buffer so they point to the correct position within the shared buffer.

Or alternatively for glDrawElements(), you could share the same index buffer, and just specify the index buffer offset.

iOS OpenGL ES Extension Support

Kaluriel — Sun, 24 Jul 2011 04:26:21 +0000

This weekend I was adding improved extension support to the Athena engine for iOS. There is a page on the Apple site that tells what device has what extensions but it hasn't been updated since iOS 4.2.

So I ran through each version of GLES on a 1st Generate iPod Touch (MBX), an iPhone 4 (SGX) and an iPad 2 (A5), printing the returned string from glGetString( GL_EXTENSIONS ) for each device.

There are a some new extensions in iOS5, some of which are iPad2 specific. But you can see from the image, each newer device supports all the previous extensions.

I haven't had chance to run it on an iPad1 yet, so it will be interesting to see if there is any difference. I've only wrote a rough idea of what version of what SDK is required to use them.

Anything with '***' does not need the extension to work and has an implementation for that version of OpenGL ES.

Source code

GL_OES_depth_texture
GL_OES_blend_equation_separate
GL_OES_blend_func_separate
GL_OES_blend_subtract
GL_OES_compressed_paletted_texture
GL_OES_depth24
GL_OES_draw_texture
GL_OES_element_index_uint
GL_OES_fbo_render_mipmap
GL_OES_framebuffer_object
GL_OES_mapbuffer
GL_OES_matrix_palette
GL_OES_packed_depth_stencil
GL_OES_point_size_array
GL_OES_point_sprite
GL_OES_read_format
GL_OES_rgb8_rgba8
GL_OES_stencil_wrap
GL_OES_stencil8
GL_OES_texture_mirrored_repeat
GL_OES_vertex_array_object
GL_OES_standard_derivatives
GL_OES_texture_float
GL_OES_texture_half_float
GL_OES_texture_half_float_linear
 
GL_EXT_blend_minmax
GL_EXT_color_buffer_half_float
GL_EXT_debug_label
GL_EXT_debug_marker
GL_EXT_discard_framebuffer
GL_EXT_occlusion_query_boolean
GL_EXT_read_format_bgra
GL_EXT_separate_shader_objects
GL_EXT_shader_texture_lod
GL_EXT_shadow_samplers
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod_bias
GL_EXT_texture_rg				
 
GL_APPLE_framebuffer_multisample
GL_APPLE_rgb_422
GL_APPLE_texture_2D_limited_npot
GL_APPLE_texture_format_BGRA8888
GL_APPLE_texture_max_level	
 
GL_IMG_read_format
GL_IMG_texture_compression_pvrtc

For more information on each extension, most of them can be viewed here. Some of the newer ones in the EXT namespace are viewable on the what's new page of the beta for iOS5, though the page calls them by the APPLE namespace still.

iOS Multithreading OpenGL

Kaluriel — Thu, 07 Jul 2011 21:38:41 +0000

LEGO Vashta Nerada

I've been meaning to do this in my engine for a while, but just never had a time.

Multithreading in OpenGL is simple enough as long as you are not accessing the same object as something on another thread.

In my case, I'm only using it for my loading thread so I will not be accessing any of the objects created until loading is complete, and I will not be rendering on the separate thread either, at least not yet, I could use it for render targets.

So first of all, the creation of a OpenGL context on iOS. The examples I'm writing here are just simple main() loops so simplify what has to be done.

Source code

int main()
{
	EAGLContext * mContext = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2];
 
	// Make context active for this thread
	[EAGLContext setCurrentContext:mContext];
 
	//
	while( 1 )
	{
		// do some rendering
	}
 
	//
	return 0;
}

Simple enough, this code most people who have written any iPhone OpenGL apps will recognise, it creates an ES2 context and bind it to the active thread.

However, now we want a separate thread that does OpenGL commands. We could use the same context, but a call binding a buffer on one thread could override to bind on the other causing invalid or wrong calls, so we would need to synchronise the threads.

Instead we create a second context that shares objects with our first one.

Source code

//
//
EAGLContext * mMainContext = nil;
EAGLContext * mThreadContext = nil;
pthread_attr_t mThreadAttributes;
pthread_t mThread;
 
//
//
int main()
{
	mMainContext = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2];
	mThreadContext = [[EAGLContext alloc] initWithAPI:[mMainContext API]
					       sharegroup:[mMainContext sharegroup]];
 
	// Make context active for this thread
	[EAGLContext setCurrentContext:mMainContext];
 
	// Create second thread for OpenGL stuff
	pthread_attr_init( &mThreadAttributes );
 
	pthread_create( &mThread,
			&mThreadAttributes,
			OGLThread,
			NULL );
 
	//
	while( 1 )
	{
		// do some rendering
	}
 
	//
	return 0;
}
 
//
//
void * OGLThread( void * inParam )
{
	//
	[EAGLContext setCurrentContext:mThreadContext];
 
	//
	while( loadingSomething )
	{
		// other opengl commands
	}
 
	// Flush changes
	glFlush();
 
	//
	return 0;
}

With this second context, any calls to binding objects to the context will not affect the other thread's context. the [API] just makes it so that I'm using the same ES version as the first context, the [sharegroup] is the shared resource group that will be used by both contexts.

However you must take care not to update an object that is in use in the main thread, and whenever you make a change that will affect the other thread, call glFlush() on the thread that modified, and then rebind on the other thread so the changes take place.

In my own engine I hold shadow states of all options set, so one problem with this system would be I would need to pass in the Context depending on the thread. Instead I wrapped a class around the context that holds the shadow states and the context, as well as a pthread_t object for the thread it is assigned to.

Then whenever I do anything that will alter my shadow states, I make a call to pthread_self() to get the current thread, and find the relevant context.

Source code

struct MyContext
{
	EAGLContext * context;
	ShadowStates states;
	pthread_t thread;
};
 
MyContext mMainContext;
MyContext mThreadContext;
 
MyContext * GetCurrentContext()
{
	int ret = pthread_equal( pthread_self(), mMainContext.thread );
 
	if( ret == 0 ) // 0 means not equal when using pthread_equal()
	{
		return &mThreadContext;
	}
 
	return &mMainContext;
}

There is only one object so far that I have found doesn't share between contexts, and that is a Vertex Array Object (VAO).

For now I'm just making my code think the extension isn't present when multithreading is enabled, but I need to come up with a solution to generate the VAO for each thread it gets used on.

Checking for OpenGL Errors

Kaluriel — Wed, 02 Feb 2011 21:38:37 +0000

Every so often I come by a bug that is annoying to debug. While I would like to write out lots of extra code that tells me exactly what went wrong with a function, it is just quicker for me to get the error type and look it up in the documentation.

For that reason, I made these helper functions. One clears the errors in OpenGL, the other outputs the error type as a string to the console and then asserts.

If the macro is used, this check can be turned off in release, and in debug the static bool within the function can be used to disable the check at runtime.

Source code

#ifdef DEBUG
#	define GL_CHECK_FOR_ERRORS()	GL::CheckForErrors()
#else
#	define GL_CHECK_FOR_ERRORS()
#endif
 
namespace GL
{
	//
	//
	bool CheckForErrors()
	{
		static bool checkForErrors = true;
 
		//
		if( !checkForErrors )
		{
			return false;
		}
 
		//
		const char * errorString = NULL;
		bool retVal = false;
 
		switch( glGetError() )
		{
		case GL_NO_ERROR:
			retVal = true;
			break;
 
		case GL_INVALID_ENUM:
			errorString = "GL_INVALID_ENUM";
			break;
 
		case GL_INVALID_VALUE:
			errorString = "GL_INVALID_VALUE";
			break;
 
		case GL_INVALID_OPERATION:
			errorString = "GL_INVALID_OPERATION";
			break;
 
		case GL_INVALID_FRAMEBUFFER_OPERATION:
			errorString = "GL_INVALID_FRAMEBUFFER_OPERATION";
			break;
 
// OpenGLES Specific Errors
#ifdef ATHENA_OPENGLES
		case GL_STACK_OVERFLOW:
			errorString = "GL_STACK_OVERFLOW";
			break;
 
		case GL_STACK_UNDERFLOW:
			errorString = "GL_STACK_UNDERFLOW";
			break;
#endif
 
		case GL_OUT_OF_MEMORY:
			errorString = "GL_OUT_OF_MEMORY";
			break;
 
		default:
			errorString = "UNKNOWN";
			break;
		}
 
		//
		if( !retVal )
		{
			printf( "%s\n", errorString );
			assert( retVal );
		}
 
		//
		return retVal;
	}
 
	//
	//
	void ClearErrors()
	{
		while( glGetError() != GL_NO_ERROR );
	}
}

Athena: Cheap(er) Per-Pixel Directional Lighting (cont)

Kaluriel — Mon, 01 Jun 2009 19:23:06 +0000

In my previous blog entry, Athena: Cheap(er) Per-Pixel Directional Lighting, I wrote how I had an idea for post process lighting calculations. Well, like many other things, it has already been done before, in fact a long time ago, 1988. It is known as Deferred Shading.

The wiki article also mentions something else that I didn't take into considering, and that is transparent objects, since there would be more than one lighting equation needed.

On the whole though, I'm glad I got a chance to implement it, one more thing I know how to do.

Athena: Cheap(er) Per-Pixel Directional Lighting

Kaluriel — Sun, 31 May 2009 21:40:52 +0000

As mentioned in Athena: More Uses for Framebuffer Objects, I have thought up a way of doing lighting using colour buffers, at the moment it is only directional lighting however.

But the great thing is, depending on how many objects are in your scene, and how much overdraw can happen, this method is faster (I think, I don't know the cost of writing to a second colour attachment).

Colour Shader

The colour shader is just a basic shader I've setup to show. First of all the vertex shader...

Source code

//
// Varying Variables
varying vec3 Normal;
 
//
// Vertex Shader entry point
void main()
{
	Normal = normalize( gl_NormalMatrix * gl_Normal );
	gl_Position = ftransform();
}

As you can see this is just a basic vertex shader, transforming a vertex position into screen space and passing the normal onto the fragment shader through a varying variable type.

Now the fragment shader...

Source code

//
// Varying Variables
varying vec3 Normal;
 
//
// Fragment Shader entry point
void main()
{
	vec3 N = normalize( Normal );
	float kDrawLit = 1.0;
	gl_FragData[0] = vec4( 1.0, 0.0, 0.0, 1.0 );
	gl_FragData[1] = vec4( N, kDrawLit );
}

This is a typical fragment shader as well, using draw buffer zero for the unlit texel colour. However, I've normalised the interpolated normal that was calculated for this texel and I'm outputting it to draw buffer one, along with another value 'kDrawLit'.

When the w component of draw buffer 1 for this texel is set to 0.0, the texel will not have any lighting calculations performed on it in the post process. I came up with this when I started thinking about rendering a HUD before the post processing.

I've chose just to output red as a colour, anything is fine, such as a texture that is mapped to the object in question.

Per-Pixel Lighting Shader

Again, another simple vertex shader, passing a transformed vertex and texture coordinate to the fragment shader...

Source code

//
// Varying Variables
varying vec3 v_lightDir;
varying vec3 v_halfVec;
 
//
// Vertex Shader entry point
void main()
{
	//
	v_lightDir = normalize( gl_LightSource[0].position.xyz );
	v_halfVec = normalize( gl_LightSource[0].halfVector.xyz );
 
	//
	gl_TexCoord[0].xy = gl_MultiTexCoord0.xy;
	gl_Position = gl_Vertex;
}

Now for where the magic happens, the fragment shader, it uses two textures. The 'baseImage' sampler is for the colour buffer, whilst the 'nrmImage' is used for the normal texture we wrote...

Source code

//
// Uniform Variables
uniform sampler2D baseImage;
uniform sampler2D nrmImage;
 
//
// Varying Variables
varying vec3 v_lightDir;
varying vec3 v_halfVec;
 
//
// Fragment Shader entry point
void main()
{
	// Get texel colour and normal data
	vec4 kTexelColour = texture2D( baseImage, gl_TexCoord[0].xy );
	vec4 kNormalColour = texture2D( nrmImage, gl_TexCoord[0].xy );
 
	// Don't Perform Lighting on a non-lit texel
	if( kNormalColour.w == 0.0 )
	{
		gl_FragData[0] = kTexelColour;
		return;
	}
 
	// Calculate Ambient
	vec4 kAmbient = gl_LightSource[0].ambient * kTexelColour;
 
	// Process Light Direction and Normals
	float NdotL = max( dot( kNormalColour.xyz, v_lightDir ), 0.0 );
	vec4 kColour = kAmbient;
 
	// Add Diffuse and Specular is NdotL is greater than zero
	if( NdotL > 0.0 )
	{
		// Calculate Diffuse
		vec4 kDiffuse = ( 1.0 - kAmbient ) * ( gl_LightSource[0].diffuse * kTexelColour );
		vec4 kSpecular = gl_LightSource[0].specular;
		float kShininess = 60.0;
 
		float NdotHV = max( dot( kNormalColour.xyz, v_halfVec ), 0.0 );
		kColour += kDiffuse * NdotL;
		kColour += kSpecular * pow( NdotHV, kShininess );
	}
 
	// Write Pixel Colour
	gl_FragData[0] = kColour;
}

As you can see, if the w component of the normal texture is 0.0 then the colour value is outputted as it is. If not, using the normal and the light currently setup, the colour is modified to be lit before being outputted.

I've just used a simple Blinn shader for calculating the lighting.

The Application

Now for the application side of things, below is just some quick sample code for what I used for my example. As you can see I've used a unsigned byte to store the normal, a floating point texture may have better accuracy at describing it though.

Source code

//
//
namespace CommonApp
{
	enum TextureTypes
	{
		kColour,
		kNormal,
		kDepthStencil,
		kNumTextureTypes,
	};
 
	//
	const int kWidth = 800;
	const int kHeight = 600;
 
	//
	GLuint l_frameBuffer;
	GLuint l_textures[kNumTextureTypes];
 
	//
	GLuint l_colourProgram;
	GLuint l_lightingProgram;
}
 
//
// Use alternate INTERNAL_FORMAT if floating point textures are not supported
//#define INTERNAL_FORMAT GL_RGBA
#define INTERNAL_FORMAT GL_RGBA32F_ARB
 
//
//
void CommonApp::Init()
{
	// Code to load colouring shader program
	// ...
 
	// Code to load lighting shader program and setup uniform variables
	// ...
 
	// Generate Textures
	glGenTextures( kNumTextureTypes, l_textures );
 
	// Create Colour Texture
	glBindTexture( GL_TEXTURE_2D, l_textures[kColour] );
	glTexImage2D( GL_TEXTURE_2D, 0, INTERNAL_FORMAT, kWidth, kHeight, 0, GL_RGBA, GL_FLOAT, 0 );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
 
	// Create Normal Texture
	glBindTexture( GL_TEXTURE_2D, l_textures[kNormal] );
	glTexImage2D( GL_TEXTURE_2D, 0, INTERNAL_FORMAT, kWidth, kHeight, 0, GL_RGBA, GL_FLOAT, 0 );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
 
	// Create Depth Buffer
	glBindTexture( GL_TEXTURE_2D, l_textures[kDepthStencil] );
	glTexImage2D( GL_TEXTURE_2D, 0, GL_DEPTH24_STENCIL8_EXT, kWidth, kHeight, 0, GL_DEPTH_STENCIL_EXT, GL_UNSIGNED_INT_24_8_EXT, 0 );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
 
	// Generate Framebuffer and attach textures
	glGenFramebuffersEXT( 1, &l_frameBuffer );
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, l_frameBuffer );
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, l_textures[kColour], 0 );
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT, GL_TEXTURE_2D, l_textures[kNormal], 0 );
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, l_textures[kDepthStencil], 0 );
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_STENCIL_ATTACHMENT_EXT, GL_TEXTURE_2D, l_textures[kDepthStencil], 0 );
}
 
//
//
void CommonApp::DeInit()
{
	glDeleteFramebuffersEXT( 1, &l_frameBuffer );
	glDeleteTextures( kNumTextureTypes, l_textures );
}

Just the usual code as you can see for setting up a frame buffer. Now for rendering the scene...

Source code

//
//
void CommonApp::Render()
{
	// Use Frame Buffer
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, l_frameBuffer );
 
	// Set Draw Buffers
	const GLenum kBuffers[] = { GL_COLOR_ATTACHMENT0_EXT, GL_COLOR_ATTACHMENT1_EXT };
	glDrawBuffers( 2, kBuffers );
 
	// Use Shading Program
	glUseProgram( l_colourProgram );
 
	// Perform Rendering
	// ...
 
	// Reset Draw Buffer
	glDrawBuffer( GL_COLOR_ATTACHMENT0_EXT );
 
	// Reset Frame Buffer
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 );
}

I've set it up so that drawing to draw buffer zero writes to the colour texture, whilst drawing to draw buffer one writes to the normal texture, to reflect what is being done in the shader.

You don't need to use the colour shader I described up above, as long as it writes out the normal and an unlit colour, any shader can be used for this process, but for demonstration I've made it in this example that all geometry is drawn with this shader program.

Finally with our scene rendered, we can moved onto the final post processing stage...

Source code

//
//
void CommonApp::PostRender()
{
	glActiveTexture( GL_TEXTURE0 );
	glBindTexture( GL_TEXTURE_2D, l_textures[kColour] );
 
	glActiveTexture( GL_TEXTURE1 );
	glBindTexture( GL_TEXTURE_2D, l_textures[kNormal] );
 
	glUseProgram( l_lightingProgram );
 
	// Render Fullscreen Quad
	// ...
}

Attaching the colour and normal texture, using the per pixel lighting shader program and drawing a quad. The images within this blog are the final result (showing a comparison would be useless since they look the same).

One downside to this is that all texels have to use the same shininess value, however the alpha value of the colour buffer could be used to control this.

It is only a start, I need to performance check it at some point to see if it gives better or worse performance and under what conditions.

Download Source: Per Pixel Lighting (MacOSX)

Athena: More Uses for Framebuffer Objects

Kaluriel — Fri, 29 May 2009 20:21:45 +0000

As I was upgrading my engine to the latest version of OpenGL, I noticed how my depth buffer was broken again (I use it for debugging my scenes when on the debug menu), and despite many changes, I was still having trouble getting it to display properly.

The glReadPixels() function with GL_DEPTH_COMPONENT was working, but I was having no luck at getting it displaying at any colour other than white without converting it first before writing it to a texture with glDrawPixels() - on reflection a floating point texture might have made this easier.

Anyways, when looking for answers, I found a way of using frame buffer objects to write out to multiple colour buffers, which allowed me to modify my Blinn shader to render a scene and the depth buffer to texture at the same time.

First of all, the shader needs to be shaders, instead of gl_FragColor, we use gl_FragData[n], where n is the index of the colour buffer we want to write to.

Source code

//
// Varying Variables
varying float v_farPlane;
varying float v_nearPlane;
 
//
// Fragment Shader entry point
void main()
{
	// Write Pixel Colour
	//gl_FragColor = vec4( 1.0, 0.0, 0.0, 1.0 );
	gl_FragData[0] = vec4( 1.0, 0.0, 0.0, 1.0 );
 
	// Write Depth
	float kDepth = 1.0 - ( gl_FragCoord.z / gl_FragCoord.w ) / ( v_farPlane - v_nearPlane );
	gl_FragData[1] = vec4( kDepth, kDepth, kDepth, 1.0 ); // Luminace style
}

And finally when binding your frame buffer object.

Source code

//
//
void RenderTarget::Setup()
{
	// Create Frame Buffer
	glGenBuffers( 1, &m_frameBuffer );
 
	// Bind Frame Buffer
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, m_frameBuffer );
 
	// Attach texture to receive colour
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, m_colorTexture, 0 );
 
	// Attach Texture to receive depth buffer
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT, GL_TEXTURE_2D, m_depthTexture, 0 );
 
	// Attach Depth and Stencil Buffer (same object since my gfx card doesn't support them being separate)
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, m_stencilDepthBuffer, 0 );
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_STENCIL_ATTACHMENT_EXT, GL_TEXTURE_2D, m_stencilDepthBuffer, 0 );
}
 
//
//
void RenderTarget::StartRender()
{
	// Bind Frame Buffer
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, m_frameBuffer );
 
	// Set which index draws to which colour attachment
	const GLenum kBuffers[] = { GL_COLOR_ATTACHMENT0_EXT, GL_COLOR_ATTACHMENT1_EXT };
	glDrawBuffers( 2, kBuffers );
}

The call to glDrawBuffers() sets where gl_FragData[x] is being wrote to, I've specified there are two indexes, the first one points to colour attachment 0, and the second points to colour attachment 1.

Now when an object is rendered using that shader, it will output the normal colour buffer to colour attachment 0, and output the depth buffer to colour attachment 1.

Also, don't forget to reset the draw buffer destination after you're finished with it.

Source code

//
//
void RenderTarget::EndRender()
{
	// Reset draw buffer destination
	glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
 
	// Unbind frame buffer and all attachments
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 );
}

I will probably remove the glBindFramebufferEXT() call to unbind the frame buffer at some point, so that the same frame buffer gets used for all render targets, only the attachments get changed.

I've read it is faster this way. For more information on this, there is this great article on GameDev.net about it called, OpenGL Frame Buffer Object 201.

I probably won't use this for writing out the depth buffer, but it did give me some ideas for per pixel lighting.

Athena: OpenGL 3.0 Upgrade in Progress…

Kaluriel — Thu, 28 May 2009 17:08:20 +0000

I just upgraded to the latest version of gDEBugger, and it kept notifying me that a lot of my code is using deprecated functions as of OpenGL 3.0.

So I have begun the long task of converting code and shaders alike, hopefully in a positive step since it will mean my DirectX 10 port of the Athena engine will have little modifications to work like the OpenGL and vice versa.

These functions are the first on my list, they are used for rendering my geometry.

glTexCoordPointer()

glColorPointer()

glNormalPointer()

glVertexPointer()

These have been replaced with glVertexAttribPointer(), a more useful system so you can specify custom attributes a vertex has, and link them to attribute variables in shaders (shaders are required now for everything like DirectX 10). So for a simple array of vertices, I linked them to attribute variable in my shader which was bound to location 0.

Source code

//
// Bind VBO Object
glBindBuffer( GL_ARRAY_BUFFER, m_vertexBuffer );
 
//
// Enable vertex attribute streaming on location 0
glEnableVertexAttribArray( 0 /* location */ );
 
//
// Set attribute offset, size, and type details for location 0
glVertexAttribPointer(	0, /* location */
			4, /* components */
			GL_FLOAT, /* type */
			GL_FALSE, /* normalize */
			sizeof( float ) * 4, /* stride */
			0 ); /* buffer offset */

I found out shortly after however that the index I was using for my vertex attribute is a reserved index by nVidia for their built-in attributes, as are 12 others.

0 - gl_Vertex
2 - gl_Normal
3 - gl_Color
4 - gl_SecondaryColor
5 - gl_FogCoord
8 - gl_MultiTexCoord0
9 - gl_MultiTexCoord1
10 - gl_MultiTexCoord2
11 - gl_MultiTexCoord3
12 - gl_MultiTexCoord4
13 - gl_MultiTexCoord5
14 - gl_MultiTexCoord6
15 - gl_MultiTexCoord7

So in the interest of keeping things sane I changed the location index to be 16, all that was needed was updating my shaders to use attributes rather than gl_Position, etc.

Source code

//
// Vertex Attributes
attribute vec4 a_vertex;
attribute vec2 a_texCoord0;
 
//
// Vertex Shader Entry Point
void main()
{
	//gl_TexCoord[0].xy = gl_MultiTexCoord0.xy;
	gl_TexCoord[0].xy = a_texCoord0;
 
	//gl_Position = gl_Vertex;
	gl_Position = a_vertex;
}

You may have noticed that I don't multiply my vertex by any transformation matrices, this is because my vertex coordinates for 2D are always in the range of -1.0 to 1.0. Doing it this way saves me changing projection matrix states whenever I want to draw 2D, so my projection matrix is always setup for 3D. Also, the source for this vertex shader program contains another attribute for the texture coordinate as well since I just copy-pasta'd my Bloom shader.

Now just two simple calls were needed to be added to my shader program before it was linked, so that the vertex attribute is bound to the correct location.

Source code

glBindAttribLocation( m_program, 16 /* location */, "a_vertex" );
glBindAttribLocation( m_program, 17 /* location */, "a_texCoord0" );
glLinkProgram( m_program );

As you can see my vertex shader has a texture coordinate as well (I'm using my Bloom vertex shader as an example), so the final code for setting up the VBO for this is.

Source code

//
// VBO layout
struct TexturedVertex
{
	float texCoord[2];
	float position[4];
};
 
//
// Bind VBO Object
glBindBuffer( GL_ARRAY_BUFFER, myVBO );
 
//
// Enable vertex attribute streaming on location 0
glEnableVertexAttribArray( 16 );
glEnableVertexAttribArray( 17 );
 
//
// Set attribute offset, size, and type details for location 0
glVertexAttribPointer( 17, 2, GL_FLOAT, GL_FALSE, sizeof( TexturedVertex ), 0 );
glVertexAttribPointer( 16, 4, GL_FLOAT, GL_FALSE, sizeof( TexturedVertex ), sizeof( float ) * 2 );

I'm sure there is a preprocessor command to get the offset of a variable within a structure, but "sizeof( float ) * 2" works as well. My code is a bit more complex than is shown here (I have a vertex format class that manages what needs to be set where, and something to managed state changes et cetera), but you get the idea of how it all works.

Well that was one big change down, on the next page of this blog entry will be another big change, replacing glMatrixMode() and glLoadMatrix().