The programming team codenamed our current milestone El Dorado after the mythical city that doesn’t really exist. Most of the stuff that we have been doing towards El Dorado… well, it isn’t ready yet. Also, a lot of it is systems which are transparent to the user (networking, refactoring, serialization, etc.) It’s all important, but it’s not glamorous. We should, however, have a few interesting things to show next week. We (well, mainly Micah) wrote up some of the work that we did on our threading and messaging system, and submitted it to an academic conference; I am pleased to report that HotPAR ’13 (the Usenix Hot Topics in Parallelism conference) decided to accept our paper, which will be presented at some point in June. I should figure out when that is…

So instead of the big Technical Status Update, which we’ll probably do next week, let’s look at a very small slice of life that makes a big difference. A lot of people ask me what it’s like doing game development, as a day-to-day process as opposed to the big picture; this is a good example of what it’s actually like on a given day, what graphics programmer thought processes are like, and so on and so forth. Also, I’ve included the picture of a tortoise next to a pile of ammunition that David refused to last week.

One of the things that I did recently was to fix the shadow code up a bit. Shadow code, you may recall, was one of the first things I did for CE, simply so I could figure out where people’s feet were. We rendered a shadow map from a fixed view point, and so you got chunkies like this:

Note that this picture looks fine – until you zoom up close, at which point you’ll see the problem. Shadow artifacts like that occur when the shadow map in question – which is basically a texture – stretches so that more than one pixel on the screen are covered by the same texel of lighting information. The end result was that – in addition to the chunky artifacts you see on the rim of the shadow, as you moved around the map close up, shadows would shimmer like a heatwave as you moved about the map. The first type of artifact can be described (loosely) as spatial aliasing; the second type of artifact is what I would call temporal aliasing (that only appears when you move.)

The general solution is to implement what are called Cascaded Shadow Maps, where you have multiple shadow maps in a big stack; areas of the screen that are closer to you are rendered in one shadow map, areas further away are rendered in another one, etc. Well, that’s no use for CE; everything on screen is about the same distance from you at all times.

I didn’t want to just change the zoom level of the shadow map as you zoomed in with the mouse wheel. In particular, I worried that it would be a shimmering mess of jaggies that would look awful, just awful, when you zoomed in and out; in other words, we’d be replacing one sort of aliasing with another sort of aliasing. I considered more and more dramatic solutions, including having enormous shadow maps that we updated sporadically and doing all kinds of other wacky stuff, until finally I wondered if the temporal aliasing caused by just zooming in and out on the shadow map would really be all that bad.

In fact, it was totally fine. Shadows now look like this:

with no noticeable change in performance, and look just fine zoomed out as well. If I had to name a reason why this works, I’d say that any possible changes in which sample we pull from the texture as we zoom in and out are masked by the small 9-tap percentage closer filtering we use on our shadow maps to give them nice, soft edges.

Moral of the story: good programmers challenge their assumptions constantly.