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);
}


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.