Regular Deferred Shading (Partially) Complete

I have the deferred shading implementation mostly complete for the non-tiled approach. The thing that I lacking is calculating screen space quads ("scissor rectangles") that determine the maximum bounds of effect for a given light. I spent a few hours trying to get it working for spot lights last night, but didn't have any luck with the math when the light originates behind the view plane. I am changing the point lights in my project so that they have a limited sphere of influence.

The forward and deferred paths lead to completely identical images, but the deferred path is currently slower due to the fact that a full-screen quad is being rendered for each spot and point light. That requires too many texture reads for deferred shading to surpass forward shading without significantly increasing the complexity of the scene geometry.

Below is a screen of the deferred shading output for the "sponza" scene available from Crytek: http://www.crytek.com/cryengine/cryengine3/downloads

I also need to give an in-class presentation today on the status of my project. To that end I have made a powerpoint, which is available at: Dropbox link.

The next thing that I need to work on is calculating the scissor rectangles for point lights. I found several sources on how to do this for point lights, so I am going to focus on getting point lights working first, then come back to spot lights at the end of the project if I still have time. Next, I will work on the tile-based shading calculations. Finally, I will add the post-processing effects and create a tile-based solution for them as well.

Model Loading Complete

I've finally got the model loading as complete as it needs to be for the purposes of this project. As I found out after writing a lot of the code myself, ASSIMP contains options for simplifying loaded scenes into flat structures (one node, with a bunch of pre-transformed meshes). The ASSIMP implementation tends to generate some errors on the COLLADA models that I've plugged in from Google's 3d warehouse. My implementation, on the other hand, was orders of magnitude slower; I decided to scrap it in favor of reasonable speed and just use model files that don't cause the importer to mess up.

Here is a sample image using some random ikea furniture and a bizarre amount of spiders, which shows textures working. Due to perceived time constraints on getting this project finished,  I'm not going to do anything fancier than just using diffuse color textures. Plus, none of the models that I've come across include textures for bump- or normal-mapping.

Because some models have textures and others don't, I experimented with using preprocessor defines in the shaders to help me generate two different shaders. While this wasn't really needed for such a simple case, I wanted to make sure that it worked as expected for the when I have to make 16 or 32 shader combinations.

I hope to set up the lighting system and non-tiled deferred rendering path by class on Monday so that I have something to present. Even if I get that far it doesn't even seem like half of the coding portion of the project would even be done; there is still a ton to do, and I hope I can finish it all in three weeks.

Model Loader Added

After much searching and rejecting a few candidates that didn't integrate well with what I was trying to do, I finally found a model file parser that is suitable for my project. The loader is called "Assimp: Open Asset Import Library," and can be found at: http://assimp.sourceforge.net/. I've included a screenshot showing the street scene from our 3rd homework assignment with a spider model added to it. The image was generated using a simple shader that just outputs the view-space normals as a color. The spider model was included in the assimp download package.

One neat thing about assimp is that it can import a huge variety of file formats, which should allow me to find some interesting geometry to use in my project. As of now, the program only uses the position and normal data to build objects, but I plan to also include support for different materials, textures, and vertex color data for untextured models. I'm not a huge fan of the included model because it includes a split down the center of the face.

My next step will be to implement some kind of singleton objects for managing shader and texture pools and editing the forward renderer to support an arbitrary number of lights (through a multi-pass approach). I also need to set up a system to include simple animation in the scene (probably entire objects moving in circular paths). Once those tasks have been completed, I can finally begin working on the tile-based deferred rendering.

The plan is to implement tiling for both lighting and post-processing. For the lighting stage, the entire light calculation will probably be done in a CUDA kernel. I was looking at an implementation for tile-based lighting in directX (available here), and noticed that it relied entirely on the directX computer shader. Since openGL doesn't yet support anything similar as far as I have been able to tell, it will be necessary to use CUDA instead. For the post-processing, my approach will be somewhat different. The tile classification will still occur in CUDA; however, rendering to the framebuffer will be done by a series of calls to all of the possible shader combinations. Using 4 or 5 post-processing effects will require 16 or 32 shaders to account for all combinations; the shaders will be permuted from an uber-shader using preprocessor defines.

Open Sourced

My final project will be open sourced and hosted at:
http://code.google.com/p/cis565-deferred-shading-project/

As of now, there is hardly any of my code in the repository. For convenience, I plan on using the following libraries, which I have been accustomed to using on the homework assignments: freeglut, glew, glm, and SOIL.

In preparation for my presentation on deferred shading, I have been reading quite a few papers and articles on deferred shading. This has given me a better idea of how I want to set up my g-buffer for the targeted effects. With the current plan, four 32-bit frame buffers will be used, arranged as follows:

• 0 - diffuse.rgb + materialID
• 1 - normal.xy (16 bits each)
• 2 - depth (24 bits) + flags
• 3 - screenSpaceVelocity.xy + objectID

One bit of the flag value will represent the sign of the z component of the normal. However, the storage scheme for the normals will probably be changed. Patrick sent me a very good link about different compression methods that can be used for the normals: http://aras-p.info/texts/CompactNormalStorage.html

First Post

The proposal for my project can be found at: http://sites.google.com/site/smt565files/ProjectProposal.pdf

My first step is going to be to figure out what I am going to use for scene geometry. Because my aim is to include motion-blur as a post-processing effect, I need to include animation of some sort. My original thought was to make a simple cubic room with some crudely animated models (i.e., the whole model moves as one unit) flying around inside of it. I didn't plan on using any sort of scene graph, rather each object would have a single world space transform associated with it. The animation component would just be circular paths and rotations around the center of each object. Unfortunately, I haven't come across a suitable library for loading 3d model information.

Now, I am hoping to use simple 3d primitives such as cubes and spheres. I envision a scene full of bouncing balls and light-casting, rotating, stalactites coming down from the ceiling. Seeing as how the project is about a rendering process, I don't think the scene geometry should be very consequential. However, the envisioned scene should provide enough movement and edges for my purposes.

As mentioned in my proposal, the inspiration for the screen-space classification for lighting and post processing comes from the following two sources:

• Hutchinson et al, "Screen Space Classification for Efficient Deferred Shading"
• Johan Andersson, "Parallel Graphics in Frostbite - Current and Future"

At some point I am going to open-source the project code. I'm still not sure whether I am going to use a model loader and what license it would be subject to, so I am going to hold off on doing so for the time being.