Following up his recent article on practical fluid dynamics, Neversoft co-founder Mick West further explains the technical details - including source code - of creating dynamic fluid systems such as smoke for video games, using nothing more complex than basic algebra.

On creating smoke, West notes that simulating the surface of the fluid isn't the goal, rather its is more interesting to visualize substance suspended by and carried around by the fluid. "With water, we might have silt, sand, ink, or bubbles. In air, we could see dust, steam, or smoke. You can even use the velocity field techniques outlined here to move larger object, like leaves or paper in a highly realistic manner."

He continues: "It's important that what we're talking about is a suspension of one substance in another. We are generally not so interested in simulating two fluids that do not mix (like oil and water)."

Modeling smoke should be approached as a suspension of tiny particles in the air and not as a gas: "These tiny particles are carried around by the air, and they comprise a very small percent of the volume occupied by the air. So we do not need to be concerned about smoke displacing air."

To simulate smoke, West suggests adding "another advected density field, where the value at each cell represents the density of smoke in that region." In his accompanying code, he refer to this as "ink," as it's similar to the density of air, except "the density of smoke or ink is more of a purely visual thing and does not affect the velocity field."

Posted by Eric Caoili at 02:56 PM | Permalink | Comments (0)

For this week's featured video, Game Creators CEO Lee Bamber describes how the company approached Intel about obtaining logos to use with their Windows Vista and Direct X10 game creation tool, FPS Creator X10, only to come away with the goal of integrating multicore support with its software.

Game Creators picked three software-slowing areas to target with multicore, the first being artificial intelligence: "The problem was that when we had a hundred characters rendered into the scene, the CPU slowed down on a single core because there was just too much AI processing going on. We spread out the AI calculation across all the cores, which brought our speed back up... so we could have a hundred characters running around a confined space, and we also got our performance back."

The team then accelerated line mapping, having found that with a single core, calculating all the shadows in a scne with lots of light could sometimes takes up to 180 seconds. "When we otimized with multicore technology on a quad core, the same thing took 53 seconds. So, [there was] a dramatic reduction in the waiting time to be able to go and play the game."

The third area Game Creators focused on was video capture. The studio wanted players to be able to capture footage to share with their friends and actually incorporate into their game-making process for cutscenes, but as soon as the feature was added, the game slowed to a crawl: "What we decided to do was get a separate core, and [we] said that core is just going to be video capture. That core sits there, and then captures the game which was on the other cores. The idea is that when you switch on video capture, the game doesn't slow down. So, you can capture the video at full frame rate, and you actually get a cool video at the end of it that you can use during your game-making process."

Posted by Eric Caoili at 04:40 PM | Permalink | Comments (0)

LucasArts PlayStation 3 engineer Marco Salvi has posted a conceptually simpler, more intuitive way to derive exponential shadow map (ESM) equations, which he discovered while working on an improved version of exponential shadow maps.

According to Salvi, there is "no need to invoke Markov's inequality, higher order moments, or convolutions." He goes on to rewrite the "basic percentage closer filtering (PCF)" equation with several adjustments before arriving at the more streamlined ESM occlusion term formula pictured.

He concludes: "Exponential shadow maps can be seen as a very good approximation of a PCF filter when all the occluders are located in front of our receiver (no receiver self shadowing within the filtering window). There's not much else to add, if not that this new derivation clearly shows the limits of this technique and that any future improvements will necessarily be based on a relaxed version of the planar receiver hypothesis."

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