It was anchored in Zeno simply for the sources (primitive or as particles). "Typically, we would run a very low particle simulation, which then drives the fluid and weaves particles as fuel or temperature or velocities," Hammack continues.

Once these sources get placed into Plume, all of the simulation and rendering was done on the GPU. "We chose to build in the volume renderer, the Ray Marcher, so we could tie it more closely with the sim work," Hammack adds. "We wouldn't have to judge simulation data. Almost every run of simulation gets rendered at the same time and gets judged as full renders, which cuts down on the supervisor interpretation phase of it, so they don't have to extrapolate what it's going to look like. Another thing we discovered was that the sim on the GPU runs at interactive speeds, but saving all the grid cells and data creates a bottleneck. We quickly put in options where the simulation data is never saved; it's kept in the GPU so you don't have to deal with the I/O of getting that data written and read from the file formats. That's another reason why we built the renderer in."

The software proved so flexible, in fact, that it was also used to generate air clouds, smoke and airbending effects.

"We did experimentations of doing a contrail look where it pulls vapor out of the air and distortion looks where it warps light as he's bending the air," Hammack suggests. "Night shied away from all that as being too fantastic and too difficult for an audience to understand. But pulling it from his own environment has its own challenges because he's not always in dusty or snowy environments. You have play like he's pulling dust out of cracks of things. It still leaves you with multiple looks with the air to deal with.

"The only addition for the use of fracturing technology was we chose to use Plume again for all the dust work. And that was a big win for us when we had interaction between the elements because the fire could then affect the dust as true simulation -- and the same with air and fire.

"For water, we invested a little bit of technology in the directability of it. With multiple scales of water and very long, good looks, we had to refine those tools and development in the look. For a water ball coming out of the ocean and floating right in front of you, there's so much complexity that goes into the light interaction or surface or interior detail or tightness of the refraction or if it's motion blurred. It's a bit of a puzzle to sort out all the different water looks. In some cases, we went with RenderMan and in other cases mental ray. Whenever it made sense, we tried to go through an animation stage first for all of the elements as a visualization, timing stage that we could get in front of Night and get some buy offs. It's always like an exploration of failure before you get to the right point for each one. For the water, in some cases, it was a tentacle shape that the animators could drag around that we used for timing."

And how close are they to using Plume for water?

"GPU acceleration is not quite ready for water but we're working on it," Hammack offers. "With fire, you don't really have to worry about mass and momentum. It's very gaseous and you can simplify your simulations. With water, you have to worry about the surface and mass and momentum. And with the limited memory of the GPU, you have to think about how you can represent all that data and fit it all onto the GPU card to get enough resolution to make it worth our while. You can quickly dump data back and forth between the GPU and the CPU without having to write it, but for something as complex as dealing with water surfaces and the effects that come off of it, you're going to want some stages in there of saved data."

 Bill Desowitz is senior editor of AWN & VFXWorld.