As the author describes:

"We have two things that we don't know, the reflection direction and the travelled light ray distance between the track and the bike, and those are possible to compute only using raytracing... Let's try now to fill the holes using some approximations that we can easily compute on a GPU.

"If we can render planar mirrors, we can also compute the distance of each reflected object to the reflection plane. In fact it's really easy! So we do have a measure of the distance, but not the one that we want, the distance our reflected rays travels according to the rough asphalt normals, but the one it travels according to a smooth, marble-like surface. It's still something!"

The author includes a few code examples, based on previous R&D work he did on a shipped racing title, and has even posted a followup blog entry that delves deeper into his blurring algorithm.

The cites notes the growth of integrated graphics, and notes that there are various steps developers can take to squeeze unexpected performance out of such hardware:

"Integrated graphics already dominate over discrete graphics at a ratio of nearly 2:1 in terms of market segment share, and that ratio is expected to grow substantially over the next several years.

"By tuning the scalable aspects of gameplay to the resources available, game companies can effectively expand their target user base, while still providing an optimal visual experience for everyone."

The feature goes on to explain specific benefits of the Intel program, including development assistance and discounts on development hardware.

"The key thing here is that the data is not being shared across threads as much," he explains. "There definitely is data that is being shared with the rendering thread and the graphics driver thread, but between the engine and the renderer, there really isn't a whole lot of data that is being shared. In the case of Quake 4, all the dynamic measures that are generated per frame had to be buffered and shared between the two threads, which isn't the case with Quake Wars."

In addition to the video, there are full slides available from a talk given by Kalra alongside developer Jan Paul van Waveren of Quake series creator id Software.

Referring to asset processing tools as "the ugly stepsister" of game development, West warns against ignoring their role.

He notes that, because of their simplicity, effort is often not spent to properly optimize them, which can end up eating away time later in the project.

Multithreading is a great way to make these tools more efficient, West notes. "Most PCs now have some kind of multicore and/or hyper-threading," he writes. "If your tools are written in the traditional mindset of a single processing thread, you’re wasting a significant amount of the silicon you paid for, as well as the time of the artists and level designers as they wait for their assets to be converted.

"Since the nature of asset data is generally to be large chunks of homogeneous data, such as lists of vertices and polygons, it’s generally very amenable to data level parallelization with worker threads, where the same code is run on multiple chunks of similar data concurrently, taking advantage of the cache."

Surprisingly, he even admits that "bad code" is permissible when it comes to processing tools, as long as the risks are properly weighed:

"In-house tools don’t always need to be up to the same code standards as the code you use in your commercially released games. Sometime you can get performance benefits by making certain dangerous assumptions about the data you’re processing and the hardware it will be running on.

"Instead of constantly allocating buffers as needed, try allocating a 'reasonable' chunk of memory as a general purpose buffer. If you have debugging code, make sure you can switch it off. Logging or other instrumenting functions can end up taking more time than the code they are logging. If earlier stages in the pipeline are robust enough, then (very carefully) consider removing error and bounds checking from later stages if you can see they are a significant factor.

"If you have a bunch of separate programs, consider bunching them together into one uber-tool to cut the load times. All these are bad practices, but for their limited lifetime, the risks may be outweighed by the rewards."

You can now read the full Gamasutra feature on the subject, posted as an independently authored piece within the Intel Visual Computing section, and which includes sample code (no registration required; please feel free to link to this feature from external websites).

There are two main approaches, Fosner points out. "One is the traditional way of threading for speed; you parallize things to make them faster on the GPU. You want to break your game tasks up into chunks. The other way is programming and threading for features. You take advantage of all the extra CPU power that's beyond the minimal gameplay, and take it to the point where it's increasing the user experience. What you can do is continue to add content or work while you have CPU power available. You can increase the user experience as the CPU power increases, design your game engine to be multicore aware."

In part two of the session, Fosner delves more into practical techniques:

"Games are really very challenging to thread," he admits. "If you can manage to thread your game engine successfully, you can thread anything."

After quickly recapping that original principle, Porcino moves onto evolutions of that algorithm: convex contouring ("Where marching cubes generates triangles based on face intersections, convex contouring generates polygonal shapes that enclose the convex negative space within each cell"), dual contouring ("Since vertices are placed in the interior of the cubes and not on the edges of the cubes, there is more freedom as to where the vertex can be placed"), and dual marching cubes.

Dual marching cubes was introduced in 2004. As Porcino describes:

"This method aligns vertices in the tessellation with features of the implicit function. The tessellation itself occurs on a grid that is the dual of the structured sampling grid. The result is that thin features missed, or requiring a lot of subdivision are preserved with a much sparser polygonization than that resulting from a structured grid. The method proceeds by creating an octree describing the volume to be contoured, then a dual grid of the octree is created by linking vertices at the centers of each grid cell to its topological neighbours.

"The surface is then extracted using a simple extension of marching cubes to dual grids. Since each cell in the grid is topologically equivalent to a cube, the standard marching cubes tables can be used to generate the surface interior to the cell. Since the underlying representation of the data is an octree, the resulting tessellation is much sparser than Dual Contouring or Marching Cubes."

Porcino includes visual aids that demonstrate how the dual marching cubes algorithm manages to represent geometry better than the other sampling methods, even with a lower polygon count.

Despite the cube-centric tack of the post, Porcino notes that progress is being made using tetrahedral meshes, and points to the website for Jonathan Shewchuk's UC Berkeley computer science course as a useful resource to that end.

One of Rost's focuses is lowering the barrier of entry to development with graphics hardware, a goal achieved in part by working directly with universities to get feedback and provide training. In this excerpt he discusses the importance of that angle:

"Randi Rost: Universities are where a lot of new technology gets dreamed up, where new algorithms get invented. Universities, particularly in the visual computing space, have been relatively shackled by the existing graphics hardware capabilities-where the entire rendering pipeline has been built into fixed-functionality silicon.

"This provides scant flexibility for researchers to innovate in term of rendering algorithms. Recently, within the last half-dozen years, the hardware pipeline has gotten to be more programmable, but there are still a lot of constraints.

"With our upcoming graphics architecture, built around a completely general-purpose CPU-based design, we're basically removing all the constraints for the rendering pipeline. We're telling researchers: 'Hey, here's an architecture where you can effectively do everything you want in software. There's no fixed functionality to get in your way. If you want to experiment with new rendering algorithms, with ray tracing, with hybrid rendering systems, if you want to replace the rasterization unit, if you want to have procedural geometry so that you can render spheres analytically (rather than breaking them down into polygons)-all of those things are possible.'

"It's a completely open, general, high-performance platform for highly parallel floating-point workloads, such as graphics. And, the basic programming model is simple: C++ code that targets x86 cores."

Rost goes on to discuss the opportunities this presents in hiring talent, and the importance of preparing the next generation of developers for the increasingly complex world of graphics hardware. You can read the full interview (no registration required; please feel free to link to this feature from other websites).

Top honors for best overall threaded game went to Tommy Refenes of PillowFort for his Goo! demo, which also placed in the graphics category. You can see some of the evolution of Refenes' multithreading techniques in his recent feature article.

Other top honorees include Добряк's Magic Worlds, Tandem Games' Pixel & Vega in: Crunch Time, and Яков Сумыгин's Deadly Light. The winners were narrowed down from 329 entries. All demos that placed up to fifth in their categories are available for download from Intel's site.

Open-world game environments and objects are typically spooled from the disc as players move through an area, with scene complexity often determined by the data transfer rate of spooling and the virtual speed of the player within the world.

If a world has too much complexity, then new glitches may result when data cannot be spooled fast enough as players move from one region to another. To prevent these problems, developers can restrict players' maximum speed so there is sufficient time for the world to load, and they can place limits on scene complexity and allowable variation between regions.

To allow for more complex environments, West suggest that developers take advantage of procedural content -- content generated from mathematical descriptions of underlying forms and parameters describing the specific instance of that content -- and procedural compression:

"Procedural compression is simply storing a piece of geometry as a set of procedural parameters rather than as the final model. While this is not compression in the normal sense of the word, the effects are essentially the same, only with a vastly increased (even arbitrarily large) compression ratio.

"We also trade some CPU resources, since the generation of geometry may require more CPU time than the standard spooling and decompressing of the raw data."

You can read the full technical article, which includes more information on procedural compression and solutions to the resource problems that come with the technique (no registration required, please feel free to link to this feature from other websites).

"Through image segmentation techniques," Valve's code "’simply’ tries to determine if the previous frame has been under or over exposed and a new exposure value is adjusted to compensate for problems with the previous frame(s)." Salvi notes that this method doesn't allow for reliably determining average logarithmic luminance, which in his experience has led to "an overall flat and over or under saturated feeling." So he introduces his own plan: "get rid of the exposure search through previous frames feedback and compute it the proper way!"

Salvi's method computes per-pixel logarithmic luminance and outputs that to the alpha channel; he includes a code example of the relevant math, and delves into further specific details.

As a bonus, Valve's Gary McTaggart and Chris Green, both presenters of the lectures that spurred Salvi's post, drop by in the blog's comment section to explain their reasoning behind the route they took for the Source engine's HDR implementation.

Purcell begins by laying out current issues in dealing with image processing, which becomes more challenging with the ever-increasing resolution and color demands that come alongside the evolutions in high-definition imaging. Intel's DMIP attempts to address the issue. As software engineer Alexander Kibkalo, quoted by Purcell, explains:

"Fundamentally, DMIP optimizes overall image-processing tasks within an application while individual Intel IP functions can be optimized without requiring knowledge of the environment or the conditions of the function call. DMIP provides the detailed descriptions of each task in DAG form and the appropriate preferences can then be applied for optimizing the routines.

"In terms of parallelization on Intel processors, DMIP tries to maintain a balance of the slice size. Keeping it comparatively small lets the slice fit into L2 cache and enable efficient pipelining. Splitting the slices into comparatively large sub-slices allows them to be efficiently handled by the available processor cores (for example, by 4 lines for a quad-core processor or by 8 lines for an 8-core processor). For achieving the best performance, the actual method of splitting should be tailored to the individual processor on which the application is being run."

Purcell also notes several secondary benefits:

"For example, matching the Intel IP function algorithms to the low-level optimizations for the Intel Streaming SIMD Extensions (Intel SSE) (from Intel SSE through Intel SSE4) can improve overall application performance substantially. Software developers and their application designs benefit from well-established, highly refined algorithms that address many of the most important programming operations. Intel's support network also adds value and utility to these libraries."

You can now read the full feature, which includes detailed information and visual aids.

"Metal Ray allows you to take advantage of multiple processors -- not only processors in this machine, but processors in the network," he says. "We have something called distributed bucket rendering. If I switch this one on, and the network here is connected to other machines, I could basically connect to four other machines having dual-core processors intalled, and I could then render with the power of four machines."

He then demonstrates the rendering process: "At the bottom you can see we're getting all those different buckets. Each bucket is actually representing one core of this machine I'm running here. It's helping the artists or the creator of any office or design-related building to render a lot quicker. ...We can utilize this in the games market for texture baking, for example. ...We're really harnessing the power of those multi-threaded machines."

Langmayer also demonstrates the 3D sculpting tool Mudbox.

Unlike cubemaps, which can require updating up to six textures when rendering dynamic scenes, dual-paraboloid reflections only require updating two textures.

Hawyard comments: "They won't give you the quality of cubemaps, but they are faster to update and require less memory. And in the console world, requiring less is almost reason enough to pick this method over cubemaps."

He goes on to share several reference articles and a math overview before providing code for developers to experiment with generating their own reflections with paraboloid maps.

Hayward notes that there are a couple faults to watch out for in addition to reduced quality: "One drawback of paraboloid maps is that the environment geometry has to be sufficiently tessellated or we will have noticeable artifacts on our reflector. Another drawback is that on spherical objects, we will see seems. However, with objects that have convex and concave polygons, the seem won't be as noticeable."

Refenes begins by describing his initial attitude to threading, one which proved a poor choice: he dedicated a thread to the specific tasks of collision, only calling that thread's functions when needed and keeping it in a nonfunctioning loop otherwise. Here, he explains his mistake:

"The model of having two threads sleeping and waiting for work (at least in the way in which they were waiting) was horrible. The threads waited in an infinite loop for work, and if they didn't find any, they performed a Sleep(0) and then continued waiting for work. At the time, I thought the Sleep(0) would free the processor enough so that other threads running elsewhere on the OS would be scheduled efficiently. Boy, was I wrong. The work check loop had the two processors constantly running at 90 percent to 100 percent capacity- an absolute waste of time. To understand why, picture this scenario.

"Let's say you are in charge of five construction workers tasked with paving a road. You know that you will need at least two of them to lay blacktop and at least the remaining three to grade the road, dig the ditches, and so on. Being the efficient supervisor that you are, you wouldn't think of allowing the two workers that need to lay the blacktop to sleep in the middle of the road until the blacktop is ready to be laid. No, to work as efficiently as possible, you would put all five of them to work grading and then all five paving. "

Refenes goes on to describe how he then created a new custom multi-threaded collision engine -- which he once again threw away and rewrote since that version of the game would not run on single-core machines. By the end of Act 4, he has programming another engine, one which dynamically scales based on the number of cores available.

You can now read the full feature, which includes specific technical details and visual aids.

The paper notes that though shadow volumes are able to create physically accurate shadows, thus providing a more realistic 3D scene, having an abundance of dynamic shadow-generating objects or moving light sources can affect performance.

To combat that problem, the paper covers "how shadow volumes generated on the CPU using a multithreaded approach could free up the graphics hardware from this bottleneck-creating task."

The paper also provides a shadow maps implementation based on the EmptyProject example from the Microsoft DirectX 9.0 SDK.