Tags

6.03.2011

It's a blog post! (And what a blog post!)

It has been a long few weeks. I have been reworking our lighting for too long now, and finally have some shots to show. It was an arduous process, full of demoralizing one line bugs, misunderstanding of topics and a couple of pressing meatspace issues. Sadly, these things have pushed our private beta release back a couple of times and I am sure our fan is getting impatient. We are almost there though, and will soon have a faster build and a level for all you testers to nom on.

I'd like to go into some of the issues with the old lighting system, so please bear with me. There will be plenty of images sprinkled throughout.

Visually, it looked good. We took some liberties for, which I will claim to be, stylistic reasons, but the end result I felt was pretty sharp. We essentially had a couple of lighting functions we called which were attached to our shaders. Every fragment that was drawn had to iterate through the list of lights and figure out the contribution and add these to the final color output. Now, right off the bat there are a couple of problems here. This meant every shader had to be told where every light was. We basically had a an array of light structure uniforms that we uploaded to the shaders that needed lighting information. On my test machine I had an upper limit of about 70 lights before I started getting shader size limit errors.

This man can't see

Our client side class was short-sighted and it became cumbersome to do things that we might want to do, like move lights, or remove them, but we charged ahead. When people started playing, however, there would be strange bugs that we could not figure out and after hours we pinned down to there being too many lights attached. This slowly dwindled our max number of lights down to 16. This is barely more than the OpenGL standard pipeline limit. We tried sending in lights as a texture, but at the time we were bumping into undefined behavior that we did not discover until after we culled that approach. In a way, the lower light limit was a good thing because any more passed that would cause our machines to bog down, especially if there was a lot of overdraw. There are methods to get around this low limit with this technique, but they involve doing multiple passes of our geometry, which is expensive for us. Something had to change.

One day, Sinoth read about deferred lighting. 'Hey buub0nik,' he says, 'check out deferred lighting! Might be a way to solve our problems!' So I do, and the flood gates are open. This will fix our light limit! It'll be easier to move lights! We can have custom light types! Our edge detection will be quicker! We can....(I had a lot of ideas). But we waited. There were more pressing issues with the game. It was playable, but the UI was choked, and there were other things we weren't quite pleased with. The lighting as it was, worked. We went several months with the idea of deferred in the back of our heads, and finally it was time to implement it.

The idea behind deferred lighting is to separate your lighting out from your geometry. You make a pass with your scene geometry and render relevant data to buffers. This generally includes color, normal information and depth information, plus whatever you can squeeze in for your desired effects. You then make a lighting pass, rendering your lights as geometry. Directional lights are fullscreen quads, point lights are spheres or billboarded quads, spotlights are cones. You use the buffers you made in your geometry pass to determine how the light interacts with the current fragment and write these to a lighting buffer. Combine these, and we're done.

I lied about the sprinkled images by the way. Here are some comparison shots though. Since I've blathered on long enough I will go ahead and skip the troubles I had getting deferred lighting to work. Those tales are more suited for around a campfire anyway.



BeforeAfter

BeforeAfter

BeforeAfter

BeforeAfter

BeforeAfter

BeforeAfter


There are still some issues to be handled. Some blending could stand to be tweaked, same goes for edge detection values. HOPEFULLY it is smooth sailing from here on out.

No comments:

Post a Comment