This project is a GPU-accelerated, real-time fluid simulation.
I used a demo from AMD as a base for this project, so I will highlight exactly what I did here:
Improved performance by writing a GPU-accelerated (OpenCL) Radix Sort to more effectively voxelize the particles
Added in the spout / drain to create interesting movement
Added in key controls to rotate the spout and move the drain for more movement
Implemented per-particle lifetime tracking to highlight all of the motion of the fluid
Made modifications to my custom C++ / OpenGL engine to support reading vertex attributes from multiple buffers because separating position, velocity, lifetime, etc. into parallel buffers increased the efficiency of memory reads in OpenCL
Total development time: approximately 100 hours over the span of 1 month.
Most time spent: developing and optimizing the GPU-accelerated Radix Sort (30 hours)
This project is an interactive mesh-deformation demo that allows the user to "shoot" ripples and waves into the mesh.
This project I chose specifically to drive development of my custom engine because I knew I didn't have all the functionality required to complete the project. I also started out with the hope that eventually this project would be a stepping-stone for implementing multiple lights into my engine, and I was correct (the same processes behind this project fuel my Multi-Shadow project).
While I did create my own formulas for this project (both the ripples and the waves are modified sine waves of my own design), the real hurdle was learning how to take an array of C++ objects (CPU) and pass it to a GLSL object (GPU). I knew of one way to use Uniform Blocks at the time but wanted a method that used one binding to send an entire array at once. Eventually I found a way to achieve my goals and now have support for arrays of custom objects in my engine.
Gravescape is one of my earliest games. I developed it from scratch (design to completion) in a team of 4, including myself, over the span of 5 weeks.
This project is different from all of my other projects because there was no code ownership. All members of the team contributed evenly, and at least once in all areas of the game (physics / collision, level design, architecture / logic, and even art). My primary contributions were in level design, collision, and architecture.
You can play the game here (please wait a moment for the game to load)
C++, OpenGL, GLM, Qt Framework
Multi-Shadow
This project is a graphics (OpenGL) demo I wrote to highlight my lighting and texturing. It includes a GUI with sliders and checkboxes to allow the user to play with certain values and see what makes what tick.
This project got its name by being the first of my projects to use my latest lighting system which supports multiple lights, each with their own shadow. The light data is stored in a uniform block and the shadows are stored using a texture 2D array. This setup allows me to update all lights in the scene in one place (the uniform block) and pass down only one texture uniform (the 2D array). Inside the shader I use an index from each light in the uniform block to specify which texture from the 2D array to use as the shadow map for that light.
This project also uses a version of my engine with six more months of development behind it. The ShaderInfo class has much more functionality to help the user with common shader parameters than in previous versions.
This project was my first to use OpenCL. In addition to demonstrating the power of GPU-acceleration (and looking cool while doing it) this project represents around two dozen hours of research on how to initialize, write, interface with, and display a program using OpenCL. My notes from the time are an accurate description of what I did to bring this demo to life:
"This demo was pieced together from an AMD demo that used the C bindings, a Siggraph Asia slide-deck about CL GL interop, blog posts from a Norwegian programmer in his blog “The Big Blob” who uses a UNIX system, the OpenCL API, a few Stack Overflow posts, and a whole bunch of trial and error."
Techie notes: this simulation runs 67,100,672 force calculations every frame and runs at 40 FPS on my machine, while a standard double-for loop CPU implementation runs at less than 1 FPS.
