|
Most games consider the collision
artifacts of semi-transparent particles and the environment acceptable. This is due to the abundant hardware that has
been available that performs the basic interpolation functions.
In Software Development Kits (SDKs) such as
OpenGL or DirectX, there have been render states defined that simply do the
blend function with one function call and have been available for many years. Unfortunately, art departments have been
working overtime trying to get basic particle effects in the game and looking
correct to account for this one line of code.
In recent years, there has been a
significant leap forward with the software developer's ability to define the
functions used to render a scene in the hardware: shaders. Even on cheap consumer graphics hardware, the
software developer can define almost any function imaginable (usually only
limited by available registers and functions made available to the shading
language).
Using pixel shaders, render-to-texture technology and a little bit
of math, I claim that we can more correctly simulate the volumes that the
particles were intended to represent.
The problem with current methods of
rendering particles to represent volumes is that, like most geometry in games,
they are not volumes. They are camera
facing planes rendered with the intention to never show their depth.
Now we all know that their depth does indeed
show itself if that simulated depth ever comes close to other geometry defined
with real depth. The problem arises due
to the fact that we are aliasing the depth into those camera facing polygons. We are taking the visual characteristics of a
volume in space and flattening it to a plane, then rendering the plane back in
a world with real volume characteristics.
Let's assume that we don't actually want to do this. Let's also assume that we don't want to
significantly change the art pipeline the artist would perform on their first
pass.
What do we need to better represent
these volumes? Assumptions and math. For the purposes of this article, the
following assumptions are used:
- That the
contents of each particle are intended to be uniform density. That is if we were to take a sample in
the actual volume that the particle texture was rendered from, it would be
the same density as every other sample within the volume.
- That
there are exactly two real-world boundaries implicitly defined for each
pixel in the source texture. The boundaries
are the near and far extents of the volume that the pixel is intended to
represent.
- That
there exists a plane that defines a mirror image of the boundary of the
volume for each pixel. (This
assumption will disappear in a later example).
- That the
user has access to the actual depth values rendered for the scene occluded
by the particle within the pixel shader.
|
I'm also interesting in learning more about "Baked" particle animations like the ones found in WOW. Is there a package out there that allows the particles system to be baked in?
My implementation uses the extinction factor to calculate the alpha value, which is a bit more physically based, and optionally also does a short ray-marching (for shadowing and non-homogeneous media). I called them 'thick particles'.
Unfortunately, from my experience, the default soft particles are usually preferable. At least in scenarios where the improved physical correctness isn't needed - and that includes almost all applications in games. Simply because they essentially do the same thing but are cheaper to render and easier to tweak for artists.