Kyle Hayward, a senior studying graphics research at Purdue University's computer science department, has put up a useful post processing framework sample structured to handle a myriad of post processes.

He begins by placing a PostProcessComponent (component) at the very bottom of the framework's hierarchy: "What this class represents, is a single atomic process, that is, it cannot be broken up into smaller pieces/objects. Each component has an input and an output in the form of textures. A component is also able to update the backbuffer. It is the simplest object in the hierarchy and is combined with other components to form a PostProcessEffect (effect)."

An effect contains a chain of components for implementing a single post process and handles out put from one component to another. With this arrangement, "components can be independent of one another, and the effect handles linking all the components that it owns. Because of this, each component is very simple. Also, like components, effects have inputs and outputs in the form of textures. Effects can also be enabled/disabled dynamically at runtime."

He continues: "Next we have the PostProcessManager (manager). The manager is comprised of a chain of effects, and it handles linking the output of one effect to the input of the next effect. And just like with components, this enables each effect to be independent of the next. The manager also takes care of linking the backbuffer and depth buffer to components that need it."

Because each component is independent, each one is simple in its implementation, making it easier to understand the code track down possible errors in a component. "Another nice feature about this framework is that you do not need to create a separate class deriving from PostProcessEffect for each effect. In this way, you can dynamically create your effects at run time. Most of the 'magic' occurs in the LoadContent() function inside PostProcessManager."

Posted by Eric Caoili at 02:58 PM | Permalink | Comments (4)

In this technical article, originally published in Game Developer magazine, Neversoft co-founder Mick West continues his acclaimed analyses by showcasing an algorithm for procedurally scattering objects such as trees across a game level.

West details two competing procedural content generation methodologies, teleological and ontogenic, describing the former approach as creating an accurate physical model of the environment and process to simulate the results, whereas the ontogenic approach observes and reproduces the end results of the process.

For this task of simulating randomly scattered trees, you'll want to make sure that the trees are not overlapping, yet are still evenly distributed: "What if we started off with the trees perfectly evenly distributed (say on a square grid), and then simply move each tree a random amount, but not so far that they can overlap? ... This solution actually works quite well."

West continues: "[The results] (pictured) look something like a cross between the pure random scatter and the minimum distance scatter. The trees are evenly distributed, but we still see some minor clumping, including two trees that overlap slightly. But overall this algorithm produces much nicer looking results than our first attempt, and it's simpler and cheaper to implement than the second."

Posted by Eric Caoili at 03:10 PM | Permalink | Comments (12)

In this week's featured video, Intel senior software engineer Gary Carleton provides an overview of Intel tools built to help developers thread code as easily as possible, improve performance, identify bottlenecks, and take advantage of multicore.

In addition to discussing the Intel Thread Profiler, which we've featured previously when comparing lock and lock-free code, Carleton covers several other Intel threading analysis tools and development products, such as the Intel Thread Checker and VTune Performance Analyzer.

On Intel Threading Building Blocks, Carleton describes the tool as a "template library that sits on top of the of threading APIs and allows the programmer to not have to focus on thread creation and the tread APIs in great detail." Programmers present Threading Building Blocks with a task, and it breaks up the work inside the task and partitions the work out to whatever CPU cores are available for execution.

He added that the template library has multiple purposes: : "[It makes] threading easier to release the programmer from being concerned about the details of programming, [and it makes] the program scalable. The threading building blocks at runtime will determine what CPU cores are available and actually dynamically do that. As cores become available or unavailable, it will modify the workflow according to that."

Posted by Eric Caoili at 03:27 PM | Permalink | Comments (0)