Tag Archive: Visual Effects


Particle Animations

On the art side I can slowly move towards polishing, as at least the industrial set is basically finished. One thing that I really want to tidy up are the effects. My thinking is that if they are in style, then the whole look will come together much more.

The effects were so far really soft – and somewhat realistic. Which doesn’t fit to the more comic-outline style of the textures. The explosion for example is done via an animation. So I redid the thing and animated it in a more cartoonish style:

Here is a smaller hit animation – that will show up when boxes are damaged (that effect is not yet in the game):

hit particle

A smaller hit.

It would be combined with smoke, and also sparks. Here is the animation for it, which would only really work in motion.

Spark animation

A spark – supposed to be many that fly around.

And here is the explosion.

particle explosion

Explosion!

Here are some screenshots of the explosion in action.

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.

Smooth Animation

As you very well may know, in movies and games we fake continuous movement by exchanging individual pictures at a rapid pace. We call these pictures frames and the pace in which we replace them (frame-rate) is expressed in frames per second (fps).

Most movies in theaters have a frame-rate of 24 fps, but for games the frame-rate is a lot higher (ideally at least 60 fps). Why this difference? Let’s do a little experiment:
Make sure you have a dark background on your computer desktop. Now move you mouse cursor around the screen as fast as you can and first focus on the background, then try to focus on the cursor. What do you see?
In real life (with sunlight) you would see an object move in one natural motion. But if you look at your cursor, you’ll see it at multiple locations at once and you can hardly focus on it.
The thing is, your cursor is updated at 60 fps. This means that even 60 fps does not guarantee smooth animations!
Even on a screen that updates at 120 fps, you’ll not see the cursor move in one smooth motion. Instead, the distances between the separate cursors will be the half the size as you see them now.

But how come movies get away with only 24 frames per second? First of all, they try to prevent objects moving very rapidly on screen as your cursor just did. This is why you do not see a lot fast panning shots in movies.
Secondly, since cameras have shutter speeds, fast moving objects will blur. Through motion blur, a fast moving cursor like we just had won’t display as a few separate sharp cursors. Instead, you’ll see one smudge in the form of a line between the start position and the end position of the cursor.
Since the photo-receptors in our eye do not react to change of light instantly, we perceive fast moving objects blurred as well. That is why the blurred 24 fps movies still look smooth.

To test what I just wrote down, go to this website and set the fps of the two footballs to 24 fps; one with motion blur enabled, and one with motion blur disabled. You’ll probably notice it’s pretty annoying to try to focus on the ball without motion blur.

But now back to Caromble!. After what you’ve just read it shouldn’t come as a surprise that we are currently experimenting with motion blur to make sure movement in our game feels smooth. If you’re wondering how, read this presentation.

While it’s still work in progress, here is a sneak peak:

motionblur