Going backwards: From per-pixel to light mapping

About a week ago when we posted our first screenshots, I was hoping that that would be the end of our first phase in which we focused purely on visuals. Everything was looking great: skyboxes, high-res textures, per-pixel lighting, and several unshown features were all implemented and running smoothly – that is, up until Todd (WastedYouth) finalized his map.

The process of finalizing the map basically meant copying and pasting one section of it 3x because of the symmetry of the map (kind of like copying half of your CTF map when it’s all done). This quadrupled the number of faces and lights on the map. Even after all of my best optimizations (short of writing the shader in assembly), this brought the framerate to… 12 FPS! :O

What was causing this drop? The lighting. When I turned it off, I would go back to 60 FPS (which is what Vega is capped at). I tried lowering the max. number of lights that could affect a particular face (it had started at 8), and it helped performance, but made things look pretty crappy. After all,  only allowing a face to be lit by one or two lights just plain isn’t going to make them look very good – hell, sometimes 8 wasn’t even enough!

It didn’t seem like there was any way to speed up the lighting. When every pixel on the screen is being shaded by 8 lights, it’s just plain going to be slow… unless you have some kind of monster graphics card, which we don’t want people to have to have. So, I finally I got to thinking that if 99% of these faces aren’t going to be moving, and the lights aren’t going to be changing… why not precompute the lighting?

And that’s exactly what I did! From now on, we’re going to be using light mapping for the lighting as much as possible. I’ve just implemented the first version of it, and I’m very pleased with the results so far. Here’s why I think this is going to work out great:

  • It looks just as good! Look at these two screenshots – the first one is using light mapping, and the second per-pixel lighting. Note that they look almost exactly the same – except that the light mapped-shot has 4x the framerate :) beta0043beta0049
  • Additional effects. Some effects, like shadows and light-emitting faces, really aren’t practical on a real-time basis. So, we’ll end up getting even cooler effects out of this, and they won’t have any impact on the framerate whatsoever!
  • We can still do per-pixel lighting. Faces that move, or lights that are capable of changing won’t be factored into the light map. So, we really get to have the best of both worlds!

There are some drawbacks – it will take slightly more memory to do this (but not a lot), and it will either add to the load times, or the time it takes to save a map in the editor. In the end though, it will be worth it… because who wants to play a game at 12 FPS?

Hope you guys are as pleased with this development as I am! Let us know what you think! :-D

Share/Bookmark
This entry was posted in Screenshots, Technology. Bookmark the permalink.

6 Responses to Going backwards: From per-pixel to light mapping

  1. Dynamix says:

    Looking sweet man. There really is no difference.
    Its really great that your making progress on this and at a really fast pace too.

  2. Mechadon says:

    Very nice 8] I’ll be able to enjoy running around Todd’s map a whole lot more now. I especially like that we will still be able to do per-pixel lighting for moving faces and the such alongside the lightmapping :O

  3. Carnevil says:

    Dynamix: Thanks :) BTW, did you get my e-mail? I responded a bit ago, and haven’t heard back. Just making sure you got it :)

  4. Dynamix says:

    Carn: Yeah, I got your e-mail. Just been a little is all. Check your e-mail. ;)

  5. Keo says:

    lookin awsome. I can’t wait to play dis shit

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>