Tag Archive: Lighting


Level Iterations

In our previous posts we talked a lot about juice. But in those posts, we mainly focused on main gameplay events and objects. As you might know, we more or less have all our levels finished. The gameplay stands, but the levels are all pretty rough around the edges.
We’re currently iterating over the first few levels. With each iteration, the gameplay is tweaked a little more and the graphics and lighting are made more coherent.

To give a few examples, check out the screenshots:

javaw 2014-10-07 21-47-16-07 javaw 2014-10-07 21-24-16-84

javaw 2014-10-07 21-32-11-52 javaw 2014-10-07 22-00-20-32

 

PS: We know we’ve been a bit silent on the blog lately… but believe me, it’s the calm before the storm!

 

High Dynamic Range Rendering

Now that we are getting closer and closer to an actual release of Caromble!, we have to put a lock on new graphics effects and big engine changes. Since we’d got motion blur up and running, there was one major annoyance left in how we rendered the images to screen: It was very hard (near impossible) to configure how bright or dark the final image would become. We had a basic bloom render effect in place but we had very little control over how it behaved. It basically turned our ball into an huge supernova like inferno from time to time, which made the rest of the image look really dark in contrast.

One of our main issues with rendering was that the ball was often too bright

One of our main issues with rendering was that the ball was often too bright

Enter high dynamic range (HDR) rendering. Photo enthusiasts create HDR images by combining multiple pictures (in LDR, low dynamic range) of the same scene taken under different exposures. This creates surreal images were nothing is too bright while everything remains visible. In game programming it works just the other way around. You create HDR images which allows you to regenerate the LDR images under different exposures.
Previously, all our light values in an image where clamped between 0 and 1, causing us to lose all lighting details around places where the image became brighter. With HDR, we no longer clamp the image values, giving us the full (high dynamic) range.

An old screenshot showing problems with over-exposure

An old screenshot illustrating problems with over-exposure

Once we got a HDR rendered image, we still have a few little problems. Of course, we do not want our game to look as surreal as the previous photos. Neither do lcd displays used nowadays have the capacity to produce lumen as bright as we got in our freshly rendered HDR image.
The first problem is solved by mapping the HDR image to a LDR image (low dynamic range). Basically, we  recreate those LDR images a camera would make but under the exact exposure we chose. We do this by defining a mapping function that maps 0-Infinity back to the LDR 0-1 range of our choosing such that we can display it on a monitor.
Anything below our LDR range becomes pure black. Anything above the LDR range should become incredibly bright.
So how do we produce these bright colors if monitors wont help us. We simply simulate it by enabling bloom for those values, letting the bright areas spread in their neighborhood. This finally gives us fine control over the brightness of our rendered image!

hdr

An HDR image mapped to LDR images with different exposures.

A study in light

Friday was one of these days that I just seemed completely unable to focus on the thing I was supposed to do, which is making a new level. It’s not that making levels isn’t fun, because it is. Just didn’t seem to happen that day… The funny thing is, on those days a lot of other things do happen.

Since the level I was supposed to be working is set at night, I figured it would be nice to have some lights flicker when switching on.

But how exactly do lights flicker? Deciding that this situation called for some experiments, I started my code editor and dragged out the Caromble! toolbox. First thing that came out was a simple formula: x*x. Plugging that in the function that controls the intensity of the light, we get a light that gets brighter at an increasingly quick rate. Nice, but not quite what I was after…

Then I thought of an old friend: Perlin Noise! Perlin noise is nice, because it gives you a random number that varies over time, but in a coherent way. For the light this means that it will be on for a while, then off for another, but  not switching every frame. This already gave a nice flickering effect.

The disadvantage of this method is the rate of flickering is constant throughout the whole period. I want the rate of flickering to be high at start, and then gradually decrease. I achieved this effect by taking the square root of the time parameter, before plugging it into the Perlin noise function.

And here is how that looks:

Tweaking the Light

Here are two new screenshots – Peter has been tweaking the light. It’s still temporary, since the skybox will change at some point, but it already looks much more atmospheric.

We have some good progress recently – Fred joined us to be our impressive one-person audio team. I can’t wait to hear the cow sound in action.

Some new assets are finished – more on that later.