Notice: add_custom_image_header is deprecated since version 3.4.0! Use add_theme_support( 'custom-header', $args ) instead. in /home3/cdonnell/public_html/wp-includes/functions.php on line 3753
Individual Projects « CASEY DONNELLAN



Individual Projects


Minecraft Terrain Renderer

This is a project I put together in my spare time while here at the Guildhall. I’m a big fan of the game Minecraft, but I became dissatisfied with the game’s limited draw distance and started to wonder if I could do any better myself. I found a library online that allowed me to parse Minecraft level data pretty easily and set out to render as much as I could. You can see in the video that I got it to draw quite a bit more than Minecraft does, although obviously the game itself has a lot more going on than this little renderer does. I would really like to come back to this project at some point and try to do some more with it. There are lots of other optimizations I would like to try to squeeze more terrain in while keeping a decent framerate.


Animtree/Animset Project

This was a project for my Directed Focus Study at the Guildhall. In a previous class we had created an exporter for 3DSMax for skinned skeletal meshes. After learning how to animate these meshes, I decided to go a step further and create a tool for viewing and organizing animations in a manner similar to UDK.
The application has two main parts, the “Animset Editor” and “Animtree Editor”.

The 3DSMax files I used had all animations for a character in sequence. In order to be useable, I devised the Animset Editor to “cut up” the animations into smaller chunks. This data is then saved in an XML file for later use by the Animtree Editor or game engine.

With the Animtree Editor, a user can organize animations in a hierarchy that is useful to a game engine. My version doesn’t have all of the graphical bells and whistles that UDK’s has, but it does many of the same things. The first step is to use XML to create node definitions. For instance, your game might want the ability to blend between idle and moving animations, so you could define a node that took two other node inputs, one for moving and one for idle, as well as a blend time.

The project was created using Direct3d 11 and all of the GUI coding was done using “Crazy Eddie’s GUI”


Custom Scripting Language and Compiler

I created a my own scripting language, “cwdScript”: an untyped language with a small grammar. My program reads in a script and lexically analyzing it. After validating it and providing error messages if necessary, the script is compiled into bytecode. On the 3D engine side it is possible to bind engine calls to script function calls. The generated bytecode is executed by the engine
every frame and in this way the script is able to interact with the game. Below is a sample of a simple cwdScript implementation of Quicksort.

function swap( list, i, j )
	var temp;

	temp = list[i];
	list[i] = list[j];
	list[j] = temp;

function quicksort( list, m, n )
	var key;
	var i;
	var j;
	var k;
	if( m < n )
		//chose pivot
		k = ( m + n ) / 2;

		swap( list, m, k );
		key = list[ m ];
		i = m + 1;
		j = n;

		while( i <= j )
			var doBreak;
			doBreak = 0;
			while( (i <= n) && (doBreak == 0) )
				if( list[i] <= key  )
					i = i + 1;
					doBreak = 1;
			doBreak = 0;
			while( (j >= m) && (doBreak == 0) ) 
				if( list[j] > key )
					j = j - 1;
					doBreak = 1;
			if( i < j )
				swap( list, i, j );

		swap( list, m, j );

		quicksort( list, m, j-1 );
		quicksort( list, j+1, n );


Heightmap Based Terrain with LOD

This project is a textured heightmap of Hawaii that uses a "chunk-based" level of detail system. The heightmap is broken up into a grid of 64x64 chunks. Depending on distance to the player and the intrinsic detail of the area, each chunk is drawn somewhere between a 64x64 quad mesh and a single quad. Additionally, chunks that are not within the viewing frustum are not drawn, and this culling is done in a "quad-tree" like manner. Another optimization is that all single quad chunks are rendered with a single draw call that is newly generated each frame.

The simulation runs using both Direct3D 11 and OpenGL. The terrain is lit using simple N dot L lighting.


Dynamic Shadow Maps

This video shows off my DX11 dynamic shadow mapping implementation. What is going on in the video is I am flying around the cube, changing the position of the light, and then flying around more to show off the shadow of the new light position. To be honest, this is not a perfect implementation (there are sometimes glitches on "non-shadowed" faces of the cube from certain angles and distances) but the core part of it definitely works.

So, here's how it works in a nutshell. For each frame, the world is first rendered from the position perspective of the light source. Instead of computing a color value for each pixel, the distance from the light to the pixel is stored in a buffer accessible to other shaders. Then, the scene is rendered from the perspective of the camera, as normal. Before writing the final color, however, the position of the pixel is transformed into "light-space" and its distance from the light is compared with the value stored in the buffer. If the buffer value is higher, the pixel is in shadow.

Problems arise from incongruities between the shadow map and frame buffer. This is often because the light may be far away from an object the camera is close to and is unable to provide the data resolution needed to make the shadow look good, or even consistent.


Dual Renderer

During my third module at the Guildhall I created an OpenGL/DX11 dual renderer. The video shows off some cool shader effects on a test cube: parallax, specular, and normal mapping. The environment is a Quake 3 BSP level with baked in shadow mapping. This project was a lot of fun to work on, especially the shaders. Doing shader programming is both extremely powerful and rewarding.