Graphics Update, V1.2

First off - let me make the disclaimer that this post refers to changes that will go live some time in the not-too-distant future. They're not out in the wild just yet. This is more of a "I had a busy week, but it was awesome, and now I want to share" post.

A little while ago I noticed that a lot of our CPU-side performance was going to drawing lights. Huh. "Drawing lights". This might seem like an odd statement to the non-graphics programmers out there, so let me explain.

The PA engine is a Deferred Rendering Engine. Wikipedia has a good reasonable article covering the basics here. Although it's very basic... but anyway. With deferred rendering, you render geometry once, and then you add lighting after the fact. The big advantage of deferred rendering is that you can add lots and lots of lights, and it's (relatively) cheap. To draw a light, in PA, we just render a box, or a capsule, or a sphere, using a special technique, and the shader used to render that geometry composes lighting into the scene.

Anyway... back to the story. I noticed drawing lights was starting to cost us a lot of CPU performance. Since we're a deferred engine, our technical artist started adding more interesting stuff to the scene, in the form of lights. All buildings have lights on them now. The commanders have had headlights for a while (no shock there). Explosions have lights. The fog of war is rendered as lights. Fab spray effects spit out several lights, per spray. We have lots of lights. (I actually measured one game I played to have around 7500 lights, which is... a lot.)

Anyway, when the engine was originally written we didn't have that many, so we drew them the easy way (one by one). This works great for a few dozen, or even for a few hundred. But for thousands? It adds up.

So I got a bee in my bonnet last week about instancing the lights. When a really busy game is taking 20 millseconds to execute 7000 draw calls just for lights, you need to do something... so I made some changes so that we could batch the lights. So, those 7000 draw calls? Now it's more like 7. (Actually, it's exactly 7). Not bad. It also takes a lot less time. Bonus!

That was a good start, but I noticed the framerate would still take a dive if I got close up to a massed army of several hundred units. After careful measurement, I realized in this case we were GPU bound (meaning the GPU was taking longer to perform work than the CPU). Oh dear... well, it turns out, all those units in a big mass, rendering fog-of-war lights? That was a lot of pixels getting written out, which even the beefiest GPU will start to struggle with. So that got me thinking... the fog of war is basically created as a full-screen stencil type thing that we composite over the scene. Do we really need to do that at full size? Also, notice how it's slightly blurry around the edges? Maybe we can use that...?

Turns out, we can actually render the fog-of-war buffer at 1/16th resolution. That's 1/16th of the pixels. If you are running at 1920x1080 (for a total of 2 million pixels), we would only actually perform the operation on 130,000 of them.

It makes things faster. It also has little to no impact visually. It's a win. And you'll be seeing that in a build coming your way soon (next week, with any luck).

Anyway, I'm really excited about these latest changes. It should make a noticeable difference to almost everyone out there.

I was hesitant to give figures, since it's going to vary from machine to machine, and we've not tested it widely in the office yet. I just played a game at home, and I stayed at 60fps most of the game. Experiments on a planet on my Geforce 660 at work gave 40+fps with ~600 units on-screen, up close.

Actually, I added light-count to the Ctrl+P stat screen; it shows how many API calls we make, and how many light instances.

When you get much lower it starts falling apart (ie looking ugly). But there is certainly the potential to make this a user controllable option. Bear in mind, there's probably more we can do to make this even better, too...

Pretty much, except we draw volumes not quads. Low res spheres, boxes and frusta. Now we group them by type, and dispatch while groups at one go. Much faster