I don’t use debugger. Well, I start it sometimes in (mostly futile) hope of getting a better exception stack trace. Or to look at the generated machine code in disassembly when optimizing. Otherwise, I find it mostly useless.

I don’t use “debug” build. I always build “release” with debug information. So I’m testing the same code people will use to play the game. Debug info is for getting stack info on exceptions and in some other cases.

When I encounter an error (crash, wrong logic, glitches or whatever) I follow these steps:

• Thinking
• Reviewing
• Logging
• Debugging (or, rather, taking a break)

Each step’s purpose is to get some new info about the problem. If I get new info, I go back to the first step – thinking.
As you see, debugging is actually there, but I rarely get to it. Let’s look at the steps in more detail.

Thinking

Stop and think: what can cause this problem? Is it the result of the code I just wrote/changed? What did I do to cause it? Or was it there before? What subsystems is it limited to? When does it happen, in what conditions? And so on.
Just thinking about the problem often gives some new insights about what can cause it. When you do small incremental changes (and I try to work that way when possible), the changed code is small and easy to grasp with you mind, and the problem is likely there.

Reviewing

Look at your code. Review it. Do you remember it correctly? What is actually written there? (Strange things can happen, especially if you use copy/paste/modify a lot).
Look for things you didn’t think about. Look for things that differ from what you expect them to be. If you use third-party library/engine/whatever, look at the documentation for the things you use to make sure they do what you thing they do, and accept those arguments etc.

If you find something, go back to thinking.

Logging

The code is complex. It can produce emergent results (that’s why you use it in the game, right?) So you might need to look at some values it actually produces. That’s where logging comes in.

Logging is the code that writes some text message to some log. It can be a log file, console, stderr, socket, whatever. You must be able to view all log messages though, and searching and filtering them comes in handy too.

Why logging and not a debugger?
It gives you exactly the info you ask for.
It puts it in context, with other log messages. You can see when it happened in relation to other logged events. You can see how often it happened. You can see how the value changed over time.
You can easily filter what values you log when you have multiple objects and are interested in only one of them. Or only values above a threshold. Or both.
You can surround the code with log messages and find where the exception occurs even when you can’t get a stack trace (be sure to flush you log though).
You can do all this in the release build.
You can do it even when you code for console/mobile/set-top-box/toaster/whatever.
It’s easy to turn off when you release a build. And it can be useful when the problem happens on some other computer, not on yours.

Some pitfalls:
Make it easy to automatically flush the log after every message, it’s essential when diagnosing exceptions or freezing. Or flush it always (might be slow).
Make sure you actually log what you want to log (reviewing helps here). If you write wrong value to the log, it can mislead you for a while.

Visual aids

That’s not exactly logging, but it helps a lot in games. You can write bounding box coordinates to your log, but actually seeing the box on the screen with other objects is much more useful and effective.
Make it easy to add this form of “logging” to your code. Colored lines that fade out over time are useful, for example. You can add them anywhere in your code and see them on the screen for long enough (but not forever). You can make boxes, circles, spheres, arrows or whatever you want just writing a function that conveniently adds multiple lines based on the parameters you pass.
Visualizing AI state, targets, ranges etc is extremely useful too.

Debugging

If everything else fails, you can try the debugger. But what info can you get from it that the previous steps didn’t uncover? I guess doing more thinking or taking a break is better.

Deferred rendering in Arcane Worlds

I use three ARGB8 textures for the G-buffer, so it’s 96 bits per pixel. There’s also a shadow buffer and light buffer textures. All of them are reused later in the anti-aliasing post-effect, so deferred rendering has the same video memory requirements as before.

I use stencil when rendering geometry, so I can draw sky after the scene to save fillrate.

In the G-buffer I store:

• 24-bit depth, packed into 3 channels.
• World-space normal, simply stored in 3 channels.
• Water factor (8 bit). Currently it’s either 0 or 1, but it’ll be used later to blend water based on its depth.
• Gloss factor (8 bit). Currently only used for water foam, but it’ll be used later for glossy parts of objects and buildings.
• Surface color (24-bit RGB). That’s surface albedo, not used for water.
• Glow factor (8 bit). Not used for now, it’s reserved for lava and other glowing things (like monster eyes).

So, world space pixel position can be reconstructed from depth, and we got normal and some other stuff.

Soft shadows

The huge sun in Arcane Worlds should cast very soft shadows that fade out quite fast with distance from the caster. This means the shadow density along the light ray is not monotonic, which is a problem with shadow maps. Also, I wanted sky shadows (ambient occlusion actually) because it becomes very important at night without direct sun/moon light.

So, after experimenting a bit with shadow maps, I decided to do screen-space shadows using deferred rendering.

With deferred rendering, you can apply any number of lights in screen space, as a post-processing effect. With world position and normal in each pixel, and knowing light properties (position, color etc) it’s easy to compute lighting and accumulate it in the light buffer. But the same can be done to compute shadows.

Knowing caster and light properties, one can compute the amount of shadowing for that particular light in the particular pixel, and accumulate it in the shadow buffer. The simplest object is sphere, it’s defined by four numbers: 3 for position and 1 for radius. Fits nicely in a single float4 shader register.

This means I need to add special “shadow-casting spheres” to each object I model, but I’m fine with that since I was ready to make special shadow-casting meshes for thin objects anyway. And on the plus side, far LODs can use less number of bigger spheres or no spheres at all. Filling object shape with spheres is an approximation of course, but with very blurry shadows it works fine even with a few spheres per object. The stones in the 0.04 have 3 spheres per object.

Computing sky shadow aka ambient occlusion from sphere caster is simple and intuitive, while being mathematically accurate.

Sun shadow is a bit more complex, but can be done with a variant of aperture lighting (see previous technobabble article). Looking from the surface point (the pixel being shadowed) you see two circles: the sun and the sphere caster. The amount of intersection of these circles defines the amount of shadowing. It can be computed approximately of course, since shadows are very blurry anyway.

The accumulated shadow buffer texture is used then in the full-screen lighting pass to modulate sky and sun light respectively.

Implementation details

I store shadows as light scaling factors, so 1 is no shadow at all and 0 is full shadow (no light). Sun and sky (AO) shadows are stored in separate 8-bit channels, and I have 2 more channels free for 2 more lights. That’s sky, two suns/moons and one lightning strike (or other effect light) total, all with shadows. Should be enough for this game.

The shadow accumulation is done just by multiplying those factors, both in the shader and as render target blending.

I started the implementation with a simple full-screen pass for each shadow sphere. When I got it working, I started optimizing the application of the shader.

The screen is divided into cells (16×9 currently, but that’s easy to change) and each cell has a list of data to pass to the shader (float4 for each shadow sphere). When a shadow sphere is “rendered” its affected volume is projected to the screen and its data is added to all cells that the projected area covers. Then the data accumulated in cells is passed to the shader.

You can pass up to 10 float4 registers via interpolants in shader model 3, but I chose to pass 8 at most to simplify the implementation. In fact, I pass either 8, 4, 2 or 1 registers at once. First, I scan all cells and get data from those which have 8 or more entries in the list, storing the data and the cell coordinates in the dynamic vertex buffer. So after this pass, every cell has 7 or less entries in the list and I scan them again to pass data in packs of 4. Then it’s packs of 2 and finally 1 for odd number of entries in the list.

The technique is known and is usually used in deferred rendering to apply many lights which affect small screen area each. I’ll reuse it later to apply lights too, for spells, burning trees and the like.

To limit affected screen area, I have to limit the shadow range. For sky shadow, 4 times the radius is fine without any extra tricks, but the sun shadows are longer. I found that 8 times the radius range is acceptable if the end of the shadow is faded smoothly. I use a sphere to approximate affected volume, with center shifted away from the light by 3 times the radius of the shadow sphere, and its radius set to 5 times the shadow sphere radius. That way, I capture 8x radius shadow range away from the light and 2x radius around the caster for noticeable (in daylight) sky shadow.

Code

Here comes the shader code:


#include "common.sh"

  return float4(shadow, 0, 0);
}


The sky

When I first started with the prototype I tried computing “real” sky with multiple scattering. It had spectacular sunsets, but the day sky was rather bland and the night… um… was pitch black without moon or stars.
It was really hard to tune to get the colors I wanted, due to obscure physical parameters and issues with HDR mapping. Tying it to land lighting had issues too. And the huge sun I wanted is far from small Earth-like sun expected in scattering computations.

So, I ditched it. Now I’m using an empirical sky model which is much easier to tune.
This model has three parts: vertical gradient, sun-axis gradient and circumsolar region.

Vertical gradient

Vertical gradient is the most important one – it’s used as a multiplier for both other parts. It’s a zenith-horizon color gradient with exponential falloff, so it’s “thicker” at the horizon, simulating longer light path through the atmosphere near the horizon.
Formula:
  skyV0+skyVS*exp(-skyVG/(abs(mu)+0.001))
where “mu” is the cosine of zenith-to-view angle, and coefficients are computed from zenith/horizon colors. Note: it’s mirrored using abs() at the horizon, and that 0.001 is to avoid division by zero.

Sun-axis gradient

Sun-axis gradient simulates (among other things) the anisotropic nature of Rayleigh scattering which makes sky darker at viewing directions orthogonal to sun direction. It’s the main gradient to tune when making a sunset sky.
Formula is simple:
  skyS0+(vs>0?skyS1:skyS2)*(vs*vs)
where “vs” is the cosine of view-to-sun angle. As you see, it interpolates three colors: solar, orthogonal and anti-solar.

Circumsolar region

Circumsolar region simulates Mie scattering of sunlight, producing sun disk and corona. It’s added to the sun-axis gradient, and multiplied (together with it) by vertical gradient to produce the final sky+sun color.
Formula:
  skyCS*exp(-skyCG*acos(vsd))*hf
  vsd=min(vs+(1-cos(sun_size)), 1)
where “vsd” is the cosine of view-to-sun angle, shifted by sun size and clamped to produce the sun disk, and “hf” is the “horizon factor” to cut off the sun disk and corona below the horizon. Also, I replaced acos() with an approximation, but it’s here for clarity.

The horizon

The “mu” term is actually shifted and scaled a bit to lower the horizon line, to make it look like a “small planet” with noticeably curved horizon. The area below the horizon line is darkened a bit so it looks like a fogged/reflecting planet surface.

The fog

The fog color is computed like sky, but without circumsolar region (hf=0). Then it’s darkened a bit (just like the “planet” in the background below the horizon) and applied using the simple scalar fog density term.

The fog density formula is unrealistic, crafted to produce 100% fog just before the visible land surface ends. It also fades slower vertically, so the land below you is less fogged with altitude than it could be.

The interesting effect: since the land closer to camera is visually closer to nadir (opposite of zenith), the fog color essentially changes with distance, producing a nice gradient. It could be mistaken for computed scattering, but it’s actually fake.

Aperture lighting

The huge sun I wanted should cast soft shadows (large penumbra). Also, I want multiple and dynamic light sources: moons, suns, lightning strikes. Shadow maps aren’t good at it. So, I used aperture lighting.

I’d refer you to this article for details, but here’s the essential idea: for each point, approximate environment visibility with a circular “window” (aperture). The aperture depends on the geometry only, so it can be precomputed and then used with multiple lights. So, it’s a kind of directional ambient occlusion. The circular aperture can be specified with a vector and a scalar size, fitting it in 4 scalars, or even in 3 using tangent space. The range is low, so 8 bits per component is enough to store it.

It’s easy to make soft shadows with aperture lighting – just use a large light source. A small light will produce harder but inaccurate shadows (still can be good enough). Ambient occlusion and sky light are easy to make too.

In Arcane Worlds, the apertures are computed on GPU, sampling a lot of heightmap points (actually, that heightmap is land+water now, i.e. top surface). It’s done 20 times per second at most (game logic / physics step).

Land lighting

The land is lit by sun (see paper link above for details and formulas) and sky.

The sun color is constant in shader. There’s the usual normal-to-light dot product, except I interpolate the light direction between sun and aperture vectors, weighting by sun/aperture areas, so that small aperture receives light from aperture direction mostly.

The sky light is simple: compute sky color in the middle direction between surface normal and aperture vector (approximating diffuse lighting from environment), and scale it by aperture area.

The fog is applied after multiplying the light and surface colors.

Water shader

The foam is lit like land, but ignoring the normal and associated dot products, because the foam is strongly translucent and has no real surface normal.

The sky reflection is obvious. The aperture is used to occlude the sky (approximately), interpolating on its edge between sky reflection and the approximate land lighting in the reflected direction. So that blurred land reflections you can see in the demo are actually produced by apertures.

No Fresnel term is used. The fog is applied as usual.

Some final notes

I aim at painterly look with Arcane Worlds, so I choose what looks good instead of what is realistic or physically correct.

As you might have noticed, there are no real HDR computations or mappings, the sky is tuned in low dynamic range. But a decent gamma correction is still important. The formulas above are in linear color space, but the stored and final colors are packed to gamma 2.0. Why 2.0 and not the common 2.2 monitor gamma? Because it’s faster to compute and the difference is small anyway.

The sky is tuned using “sky.nut” Squirrel script. You can edit it and it should be reloaded automatically by the demo when you save it.

This article is for those who know what a heightmap is, and who are familiar with some basic heightmap generation. If you aren’t one, you can still enjoy the screenshots and skip most of the technobabble here

Examples

Here is some fault-formed terrain:

before erosion	after erosion

And here is what my erosion method can do to a simple classic fractal-noise-generated terrain:

before erosion	after erosion

It also turns artificial forms into more natural looking ones:

Applications

As you see from the examples above, erosion can make generated terrain look much more interesting and natural. It looks even better when you add grass by slope and/or ground type.
It’s very straightforward to integrate since it modifies existing heightmap. It can be applied several times too, both for increased effect or after other terrain modifiers.
It’s useful for gameplay as well, since it makes lower areas more flat and thus easier to walk/navigate/build on.

It has some drawbacks of course.
It’s a full-terrain method, not suitable for “infinite” generated worlds. It works on maps of limited size.
It can be rather slow on large heightmaps. Especially if you want heavy erosion. So it’s probably better as offline method in your editor if your heightmap is large.

Understanding water erosion

The water starts somewhere on the terrain (as rain, water spring, whatever), then flows downhill, dissolving the soil, carrying it, and depositing it as sediment. Eventually it gets to a low point and evaporates.
The trick here is understanding (and carefully implementing) the erosion/deposition process. This involves sediment carry capacity of the flow.
At any time, the water flow can only carry a limited amount of dissolved soil. This amount depends on the surface slope, the speed of the flow and the amount of water.
If less is carried than possible, erosion happens, removing soil from the terrain and adding it to the flow.
If more is carried, deposition happens, dropping extra carried soil as sediment.
As you can see, the process can switch fast between erosion and deposition as the flow accelerates, or drops down a steep slope, or comes to a flat area.
The formula I use:
q=max(slope, minSlope)*v*w*Kq
Where slope is just a tangent, minSlope and Kq are constant parameters, v is flow speed and w is amount of water in the flow.

Droplets

I use droplet model to simulate water erosion. That is, I pick a starting point on the terrain, start with zero velocity and carried soil, and proceed moving this point, changing its dynamic variables and the terrain in the process, until all its water evaporates or it flows to a pit it can’t get out of.
Some tricky things here are:

• I use height gradient as the downhill direction. If the gradient is zero, I pick a random direction. I also add some inertia just for fun.
• I then sample next height in the downhill direction. If it happens to be higher than the current one, we’re in the pit and should either drop sediment to fill it and flow on, or die trying. When the flow goes on after filling the pit, its speed is reset to zero.
• When erosion happens, don’t remove more than the height difference (between current and next position). That is, don’t dig a pit in the place the water flows from, cut it flat at most. Digging a pit makes the process unstable, creating nasty spikes.
• I deposit to heightmap using bilinear weights. This way it fills pits better while being somewhat smooth.
• I erode the heightmap with a bell-like “brush”, to make smoother (yet somewhat wider) channels. That’s to make the final result look better too.
• A single droplet effect on the terrain is hardly noticeable (unless you use some crazy parameters). Use at least a thousand droplets for testing. Their power is in numbers.
• Erosion and deposition speed is affected by special parameters. So only some (not all) extra soil is dropped when carry capacity is exceeded, for example.
• The flow speed is accelerated by height delta on each step, and some water is evaporated as well.

Droplet sources

I use “rain” erosion in the examples, starting droplets randomly all over the terrain.
However, other effects can be achieved with non-uniform droplet distribution, like creating streams from sources, or raining more/less in certain areas.

Code sample

Here is the code “as is”. It won’t compile since it uses some external stuff, but I hope it’s easy enough to figure it out.
You can do with it whatever you want.


void HeightmapData::genDropletErosion(unsigned iterations, ErosionParams &params)
{
  float Kq=params.Kq, Kw=params.Kw, Kr=params.Kr, Kd=params.Kd, Ki=params.Ki,
    minSlope=params.minSlope, Kg=params.g*2;

  debug("  %.2f average path length, %I64u long paths cut, %I64u random directions picked",
    double(sumLen)/iterations, longPaths, randomDirs);
}


About parameters

Here are the default parameters I use:

ErosionParams()
{
  Kq=10; Kw=0.001f; Kr=0.9f; Kd=0.02f; Ki=0.1f; minSlope=0.05f; g=20;
}


Kq and minSlope are for soil carry capacity (see the formula above).
Kw is water evaporation speed.
Kr is erosion speed (how fast the soil is removed).
Kd is deposition speed (how fast the extra sediment is dropped).
Ki is direction inertia. Higher values make channel turns smoother.
g is gravity that accelerates the flows.

Other simulation methods

Droplet model is not the only one. The same flow process can be simulated with iterations on the grid, for example. However I find droplets results more interesting.
Also, there are methods to fake the erosion result. The fake isn’t as good as a “real” one, but it can be much faster. See for example “Realtime Procedural Terrain Generation” by Jacob Olsen.

Other erosion types

This article covers some water erosion only. There are other erosion types though. Rivers can do some interesting things to the terrain, for one. Coastal erosion is completely different, as well as glacial and thermal ones.
Wind erosion can be done with droplet-like method, but is very different in nature too.