The Generated Geometry sample introduced the concept of a heightmap. In that sample, a content processor reads a bitmap and uses the intensity of its pixels as height values on a terrain. A logical next step to this technique is to place objects on the terrain. This sample demonstrates that technique by placing a ball on the generated terrain.

Minimum Shader Profile

Sample Controls

This sample is based on the Generated Geometry sample. To support the added functionality, the original sample has been modified in several ways. For clarity, the sky has also been removed.

Changes to the Terrain Processor

Rolling Around on the Terrain

• The camera in this sample is fairly simple. Try taking the camera from the Chase Camera sample, and putting it into this one.
• When moving objects over a heightmap, you may also want to align them to the slope of the terrain. To do this, you'll need to calculate the heightmap's normal vectors in the TerrainProcessor. A GetNormal function would work similarly to GetHeight, except all three components of the vector would have to be interpolated separately and then renormalized. Using this normal vector, you can calculate an orientation matrix for your object.

A billboard is a way of faking complex objects without bothering to render a full 3D model. The idea is that where the 3D object would have been, you simply render a 2D sprite with a picture of the object textured onto it. If the player moves around to look at the object from a different direction, you rotate the sprite so that it will always face toward the camera, thus preventing them from ever seeing it "edge on" and being able to tell that it is just a 2D image.

This technique is obviously not as convincing as rendering a true 3D model would be, but it can be much faster, especially for large numbers of objects such as the field of grass shown in this sample. By moving the camera around, you can get an idea of what situations the billboards look good in, and also where the illusion starts to break down.

Because this billboard implementation runs entirely in the vertex shader, there is no additional CPU load from rendering billboards compared to normal static geometry. This makes it feasible to render very large numbers of billboards at a good framerate.

Minimum Shader Profile

Sample Controls

The VegetationProcessor takes in a simple landscape mesh and randomly creates billboard polygons scattered across it. These new polygons are set to render using the Billboard.fx effect, and a number of different billboard textures and sizes are randomly selected.

In the vertex shader, the billboard effect calculates vertex positions by examining the view matrix to make sure the billboard sprite will always face toward the camera. It also uses a per-billboard random number to make each billboard a slightly different shape, and to randomly mirror the textures on half of the billboards, adding variety to the results. Finally, it uses a sine wave pattern to make the top two vertices of each billboard sway back and forth, simulating the effect of wind on the vegetation. The amount of this swaying is controlled by an effect parameter, so some types of billboard can be set to sway more than others, or to remain entirely still.

Billboard lighting is calculated using the normal of the underlying landscape geometry. This means that vegetation will be lighter or darker depending on the angle of the hill that it is growing on, and will always be lit consistently with the underlying surface. In a more sophisticated landscape engine, it would be possible to make each billboard sample into the landscape texture to automatically pick up an appropriate color from the ground below it.

The billboards are rendered in two passes, using different alpha test and depth buffer settings to achieve almost correct depth sorting of alpha blended sprites without requiring them to be depth sorted on the CPU first. The comments at the end of the Billboard.fx file explain this technique in detail.

Note that although the billboard effect is included as part of the Game Studio project file, its XNA Framework Content property has been set to false. This effect will be built automatically because it is referenced by the VegetationProcessor, so there is no need for it to be duplicated in the project. It was only included here so you can easily locate the file for viewing or editing the effect code.

Bloom post-processing emulates the visual effect of bright lights and glowing objects. It does this by extracting the brightest parts of an image to a custom render target, blurring these bright areas, and then adding the blurred result back into the original image.

Because bloom is implemented entirely as a post-process, it can easily be used over the top of any other 2D or 3D rendering techniques. In addition to the more extreme glowing effects, when used subtly it provides a useful softening that can make computer graphics look more organic and help to hide artifacts from elsewhere in your rendering. Particle systems, for example, often look better with a subtle bloom applied over the top.

Minimum Shader Profile

Sample Controls

There are three stages to applying a bloom post-process.

Pass 1 Extract the brightest parts of the scene. This uses the BloomExtract.fx pixel shader, which removes any areas darker than the specified threshold parameter value. Modifying the threshold changes the look of the bloom: higher values produce smaller and better defined glows, while smaller ones produce a softer end result. To see just the result of this first pass, press X until the overlay display shows "PreBloom". Passes 2 and 3 Blur the bright areas. This is done using the GaussianBlur.fx pixel shader—first, to blur the image horizontally, and then again to blur it vertically. The shader does multiple lookups into different parts of the source texture, and then averages the results using a Gaussian curve to weight the importance of each sample. The work is split over two passes because Shader Model 2.0 is not capable of doing enough texture lookups to give a high-quality blur along both the horizontal and vertical axis in a single pass. To see the result of these blur passes, press X until the overlay display shows "BlurredHorizontally" or "BlurredBothWays." Pass 4 Combine the blurred result with the original image. This uses the BloomCombine.fx pixel shader, which has parameters to control how much bloom to include, how much of the original image to retain, and for adjusting the color saturation of both the bloom and original base images. Tweaking these settings can produce a wide range of visual effects.

Rather than just choosing a fixed set of bloom settings, you could adjust these on the fly depending on what is happening in your game. Perhaps you could make the world go greyer and more blurry when the player has low health, or increase the amount of glow for a second or two when the player gets a power-up.

You can also adjust bloom settings to mimic how the human eye responds to changing light levels. If the player is in a long tunnel, turn the bloom up very high so any areas of the outside world that are visible past the end of the tunnel will burn-out to white and have a huge glow around them. After they leave the tunnel, gradually fade the bloom down to a level where they will be able to see normally again.

For a higher-quality bloom, you can render your world using high-dynamic-range (HDR) lighting information, using a floating-point back buffer format to store pixels even brighter than 1.0.

The Gaussian blur used in this sample could be replaced with any other kind of filter. For example, you could use a blur pass with large sample offsets to create various kinds of lens-flare effects.

The blur-and-combine pass is a great place to include other kinds of image manipulation. In addition to using the saturation adjustment used in this sample, you could do tone mapping here, or tint the image, or blend in a layer of noise or film grain. This infrastructure is a good starting place for other kinds of post-processing, too, opening up the non-photorealistic world of edge detection, embossing, pencil sketch rendering, and other such techniques.

The most substantial changes are in the BloomComponent. Here, we must update the sample to use XNA Game Studio 2.0 revised render target APIs. First up, we need to change the type of the field resolveTarget. In version 1.0 when resolving a render target or back buffer, the destination of the resolve had to be a Texture created with the special flag ResourceUsage.ResolveTarget. Many found this pattern confusing, and in XNA Game Studio 2.0 this flag has been removed. Instead, we simply create an instance of the type ResolveTexture2D with no flags at all.

The next change comes in BloomComponent.Draw. In this function, we used to temporarily disable the depth stencil buffer to avoid writing to it, and then would set it back when finished. This is actually not necessary. The draw function uses SpriteBatch, which draws with the depth buffer disabled. So, we do not need to do anything to "protect" the buffer: it could not have been modified anyway! In the new version of the sample, we avoid changing the depth stencil buffer because doing so leaves the current render target in an undefined state.

Finally, we must update DrawFullscreenQuad. In the first version of this sample, the function ResolveRenderTarget was used to explicitly resolve the current renderTarget. This method is now considered obsolete and causes a compilation error if used in your code. The actual resolve operation occurs automatically when a new render target is set (for example, a call to SetRenderTarget). So, we replace the call to ResolveRenderTarget(0) with SetRenderTarget(0,nothing). This resolves renderTarget and sets the current render target back to the back buffer.