AFX Spell-Design Blog #3 (Fire Tower)

I'm back, with another update on this monster Arcane-FX spell that will consume us all! The previous installments of this blog can be found at :
AFX Spell-Design Blog #1 (Fire Tower)
AFX Spell-Design Blog #2 (Fire Tower)

I've been working on the emergence of the mighty tower, and encountered devilish difficulties along the way -- primarily in regards to the creation of a giant cloud of dust and smoke. Not all are overcome, but I've been experimenting with different methods. My folly has been to persist to the point of neglecting other simpler spells that need to be created. Damnation!

Here is the current emergence, from different angles:
www.arcane-fx.com/visuals/blog3-movieA.avi <2mb>
www.arcane-fx.com/visuals/blog3-movieB.avi <2mb, high view>
www.arcane-fx.com/visuals/blog3-movieC.avi <3mb, close up>

Alright, where do I start? I'm insane! The cause of this condition can be put into a single word: sorting.

Underground the world burns, and from this comes the Fire Tower, and its emergence had to be something of smoke and fire. I envisioned it creating a huge cloud of smoke with burning rocks or embers shooting out, their own smoke contributing to the shape of the cloud. Early tests revealed a large number of problems, for while it was possible to create a good look at a single moment in time, in motion the effect was often a jittery mess. TGE was having trouble determining what was in front of what, and often choosing different orderings for different frames. With Jeff's help we dived into the source to sort out the sorting, discovering along the way that there were many problems to overcome.

In retrospect perhaps we should have just had it fade-in, and sold it with sound effects of people screaming: "A giant tower of fire!".


=== Problem #1: Emitter-Level Sorting ===

Particle emitters in TGE are sorted according to their bounding boxes, which by default grow dynamically to encompass the particles they emit. Often though this can cause a problem, because a dynamically-changing bounding box is also changing in relation to other (often static) bounding boxes for other component types (other emitters, models, etc.) -- and thus, sort order can change unexpectedly. AFX allows the user to force a specific, static bounding box for its particle emitters, and this often is enough to solve sorting problems.

But look at the smoke explosion: besides the core smoke emitters, there are 20 ballistic emitters that shoot out from the cloud and generate smoke of their own. How am I to choose a unique static bounding box for each of these emitters that will sort in the right order for any camera angle? Impossible, I think. Perhaps though some procedural way could be found.

Instead I decided to start looking at how to merge particles from multiple emitters into one entity that can do its own sorting: a Particle Pool. Emitters can specify that they belong to a certain pool. When an emitter is part of a pool, its usual rendering method is ignored. The pool now is what renders, and it renders all particles that belong to all of its emitters, all at once. The advantage is that now I can sort all of these particles together, creating proper spatial relationships between them, enforcing a correct back-to-front draw order based on distance from the camera; no longer will one particle system suddenly pop in front of another, as long as they're members of the same pool.

There are essentially two performance downsides to this approach. One, I'm doing more sorting, which for large particle systems can be computationally expensive. And two, because a large number of emitters and hence a large number of particle systems can now all share one bounding box, Torque considers the whole pool as one rendering entity which by itself is tested for visibility with the camera. If all I see is half the pool, because some of its emitters are off-camera, I'm nevertheless rendering all their particles -- pointlessly.

=== Problem #2: Inside the Bounding Box ===

Just about everything with this effect is supposed to be big, but what's especially big is this giant smoke cloud. But a giant cloud needs a giant bounding box, otherwise it will disappear suddenly when the camera swings away. In fact, the bounding box is so big that the camera will often be inside it! After all, I want to be in the giant cloud with all the dust flying around. And what's more other glow effects and the tower itself all have giant bounding boxes. Here, we found a problem: TGE doesn't like it when you're inside the bounding box.

As it turns out, whenever the camera is inside a bounding box, TGE uses the camera's position as the sort point. This is bad because if you're inside multiple bounding boxes all at the same time, they're all sorting with the same sort point! The result is some nasty disco flashing as object's render in different orders every frame.

The original coders had foreseen this though with the inclusion of a tieBreaker buried deep within, though unused by any component type. The variable was a boolean but we upgraded it to a byte value, and now it's possible to assign to this value through AFX and use numbers to enforce a certain sort ordering in this special situation.

=== Problem #3: Particle Pop ===

My original idea for creating a decent smoke cloud, after studying image reference of forest fires and such, was to create a particle system that contrasted smaller, lighter particle atop larger, darker ones. This idea worked fairly well in practice, but even with the Particle Pool doing per-particle sorting, there was still a problem. My particles were popping.

The obvious blend modes to use when rendering smoke particles are the matte, non-additive, non-glowy types, which rely on the alpha channel to composite the particles atop one another and the background. Setting "useInvAlpha" to true in a particle's datablock is the typical way to get such a blend mode. However, these modes create a problem as particles animate: as individual particle positions change due to their own inherent motion and the orientation of the camera, so can their ordering. One particle behind another can suddenly be in front the next frame. When this transition happens, due to nature of the blend mode, there's a visual pop. Since I was using a lot of really big particles, this popping was more noticeable than it typically is.

I might have been able to get away with replacing the large dark particles with greater numbers of smaller ones, and I may end up having to do this -- and in fact I don't think the original popping was so bad that we couldn't have lived with it if absolutely necessary. But I wanted to solve this problem.

I could only see one way to fix it: the particles had to be rendered additively. An additive blend mode simply adds the color values of particles until white is reached. There's no visible popping visible with this approach, despite the fact that particle spatial relationships are changing just as before. But additive blending is typically only used when you want to get some kind of glowy effect. How was I going to produce matte smoke?

After a lot of trial and error I found an approach that worked: a two-pass particle rendering solution incorporated into the Particle Pool. The basic idea is to simply render all particles twice, first as a darkish solid color that serves as a foundation, then with an additive blend. Ordinarily you would never know what base color your additive particles would be adding atop of, be it light or dark, because who knows what might be behind your particles in the scene; but this approach is like resetting that value before you start to add.

That wasn't the only problem though. Adding all these particles together for the second layer created a big, confusing mess; particles on the other side of the cloud were just as visible as particles on the front side. I had to incorporate depth-based fading into the blending, fading off particles with distance from the clouds front extent.

And there was another problem. This fading mechanism didn't take into account the roughly hemispherical shape of the cloud. I had to incorporate a radial blend factor as well.

Phew.

This approach has two main disadvantages. It is more computationally complex than typical particle rendering, and *may* end up being a frame-rate killer on older machines. And second a certain degree of finesse is required to properly choose color values for all the particles that are a part of a two-pass particle pool, otherwise you'll notice that in the center where density is greatest they're adding up to white. In the example videos, you'll see this point occur. However in our situation, with the fire tower, the glow is appropriate (and cool).

.
.
.

And there you have it for the technical aspects of the current state of the cloud, which is definitely experimental. The main issues are performance-related I think, though there are still a few sorting issues too, so we'll see what final state it ends up in and how much of this tech ends up in the SpellPack. We may end up going back to earlier solutions, which look pretty good also.

Now let me step through some of the interesting effects that make up this emergence, besides the cloud:

=== Fireball Particles ===


Here I've used some pretty standard tricks to get a good, random mass of particles, using only one particle texture. The key is to prototype the effect using one particle type, getting good color, size, spin attributes etc., and then copy that particle type to make new versions with slightly altered parameters to create randomness. I'm taking advantage of the fact that a single TGE emitter can use multiple particle types. So here, instead of having just one fireball type, I have three, and the only thing that varies is their size.

I'm also using three emitters, each varying slightly in emission parameters and in timing to give the effect of a growing fireball. Each emitter is a cone emitter, a type that AFX provides, which is like blowing out particles from the apex of a party hat. By varying the cone angle, I get the base emitters to be wider, and the other two grow thinner. Then I use the ejectionOffset attribute, which forces the particles to emit at a specific distance from the apex; this offset is made larger with each emitter to force the particles out further and further. Finally, by controlling timing in the afxEffectWrapper, I get each of these three emitters to fire off in sequence.

=== Ballistic Fire Bursts ===

These are interesting in their construction:

AFX provides a Path transform modifier, which allows you to specify the control points of a spline and then have effects translate along it. Typically, such path points are specified as hard-coded values, possibly derived from the points of a curve in some graphics package like Maya. However, in this instance my challenge was to produce proper ballistic curves (minus air resistance) and do it in a way that was random, or as random as possible.

What I did was create functions in TorqueScript that, given an input speed and angle, produce the points needed. Since the path attribute takes a long string of three-valued points, the means of calling these functions and concatenating the whole into the needed long point string is a little cumbersome, but it works. Then, using the getRandom() function, I set variables to initialize the start angle and speed for each path. Every time the script is re-evaluated, new values are chosen, and the subsequent paths are different. Unfortunately this does not yield a random path for every execution of the Fire Tower spell, only upon script re-evaluation, but it's a step in that direction.

You'll notice in the image that I am again using afxMooring objects, as mentioned in the last blog. This object allows me to prototype my motion in a single place and then constrain other effects to it. In this instance, there are three: the fiery particles, the smoke particles, and a plane with a glow texture aim-constrained to the camera. The smoke particles are a part of the mighty Particle Pool described earlier.

=== Rock Debris ===

AFX allows you to use the Debris component effect right from stock TGE. What I did was create a number of debris objects that fire off at random angles as the tower bursts through. AFX provides a transform modifier that can be used with the debris to quickly and easily produce these random rotations.

The cool thing about debris is how they bounce off the hovel walls! (Wouldn't the coolest thing ever be the tower rising up through a hovel and destroying it? If only... If you'd pay big money to see that, speak up.)

.
.
.

You probably think I'm crazy to spend so much time on one effect and you're probably right. Secretly I think it drives Jeff bonkers. However, I'm moving on to simpler things soon, and the complexity of the Fire Tower has definitely grown the engine.

- Matthew Durante