UOIT Game Dev - Development Blog 4 - HDR and frustrations with Deferred Shading

This week...

So we've been talking about blurring techniques and how they are applied in computer graphics. Conveniently some of the techniques were already mentioned in my previous blog so the material wasn't new to me, but what had really caught my attention was the down sampling technique.

(http://www.cg.cs.tu-bs.de/static/teaching/seminars/ss12/CG/webpages/Maximiliano_Bottazzi/images/BlurAwareHeader.png)

It's a pretty neat trick. All you really need to do is scale down the image losing pixel information, then scale it back up creating a more pixelated/blurred version. I might give this a try sometime in the near future.

I've always had mixed feelings about HDR bloom. When used correctly, games can really benefit from it and look a lot brighter, however sometimes it can be too bright or too blurry (like the one below) which can outright distract the player ruining the experience.

(http://i.imgur.com/lwk8w.jpg)

But I'm really interested in figuring out how dynamic light exposure is done in games. When playing certain maps with a lot of daylight in Counter Strike Source, I would walk out of a dark area (like a tunnel) and my whole screen would be blinded by light for a split second, then it would go back to normal. Similarly, I can walk into a darker area and have my screen dimmed before adjusting to the darkness. This just seems so cool and natural, hopefully I will have some time in the future to implement this.

(http://in.hl-inside.ru/TrainHDR.jpg)

What I've been working on...

My main focus was trying to get multiple lights to render in our game. I've looked up a lighting technique called "Deferred shading" which was brought up in the first week or two of class. To be honest, I've never really understood this technique at first, calculating and rendering lights in a frame buffer really confused me.

But after reading a couple of web pages on the topic, I finally understood the concept. We essentially need to create something called the G buffer, which job is to store pixel data (position, color, normal, etc) from the rendered geometry. We then bind those textures in the light pass using the appropriate pixel data to calculate the light intensity. This is a lot more efficient since we are only calculating light data on the visible pixels in a frame.  

So I created the G buffer and the passthrough shader to output the appropriate values:

No problems there, it works fine. So then I uniformed the textures into my light pass shader calculating a simple directional light. 

It seems to work fine, the correct values are being passed over and the final result looked rather accurate. But there's 1 thing in particular that bothered me, and that was the noticeable drop in frame rate. 

Why was this happening?

Isn't deferred shading suppose to be more efficient?

I've spent hours trying to figure what was wrong and the frame rate was simply unacceptable. While I was unable to fix this issue, I've discovered something in the geometry pass that was causing the lag. 

fragPosition = position;

fragDiffuse = texture(myTextureSampler, UV).xyz;

fragNormal = normalize(normal);

for some reason, outputting the position and normal values creates a strain on processing. I simply commented out the following

//fragPosition = position;

fragDiffuse = texture(myTextureSampler, UV).xyz;

//fragNormal = normalize(normal);

and it ran smooth, but of course I wasn't able to compute the light since I had missing values. After a few more hours I finally gave up and decided to go with forward rendering for the multiple lights. It's really unfortunate but I guess I will seek help next week in hopes of resolving the issue.

Right before writing this blog, I spent the entire day working on the lighting for our night level. This is what I have so far:

It mainly consist of point lights and glowing objects for now. I plan on adding a lot more to the scene next week, hopefully it will look a lot better by then.