Particles 2: The Re-Particling

So I'm going to finally continue on from my previous particle post! Last time I talked about how I had set up my own particle system as well as how we could utilize the effects with a FBO. Today I'm probably just going to ramble on about a few things for improving the systems and other effects before finishing up with a joke. Without further adieu...

So one way of improving the systems is using Point Particles as opposed to the Billboard Particles. As mentioned before, Billboard Particles are just sprites rendered to a plane. Point Particles, in the mean time are a single vertex of a certain size with a sprite rendered on top of it. The advantage of a Point Particle vs a Billboard particle is in their efficiency. For a Billboard particle you can either calculate the position of the particle on the CPU and then translate the vertices during rendering (1 calculation on the CPU) or we can use the velocity, acceleration and current life of the particle you can calculate the new position of each vertex in a vertex shader (6 calculations on the GPU, bit better than the CPU). With Point Particles, we can do the calculations in the CPU like we do with Billboards or we can calculate the new position in the shader, with the difference being that we are only doing 1 calculation making it 6 times faster than the Billboard! This difference can be very noticeable when we have to calculate hundreds of particles. If we have one system with 200 particles, then that's either 200 calculations on the CPU, 1200 on the GPU with Billboards or 200 on the GPU with Points.

Knowing now how to help speed up the calculations, let's talk about something fun we can do. Like pseudo colliding particles! (For the record, this is being taken from a presentation done by Halo Reach's Effect Tech: Chris Tchou at GDC 2011) A method for creating pseudo collision particles is to sample from the depth buffer of the current frame and then check where the particle is in relation to it. If we see that the particle is penetrating then we can move it towards the camera until it is a suitable distance from any obstacles and, using the surface normals (which we should have output to a texture) we can then find the orientation of the face that the particle is hitting which can be combined with the particle's current velocity to figure out how it should bounce. This would involve being able to store the particles current information during each update step but gives us the appearance of particles bouncing off surfaces (e.g. if we were to do sparks flying off of a wire and bouncing off the ground). This is also cheaper to process than colliding the particle with the collision or environment mesh on the CPU which makes it even more interesting!

I could go on and ramble about a few other stuff but I'm not quite feeling up to it right now so I'm going to call it a night here. But before I do, I'm going to leave you with a horrible joke:

I applied Phong Shading to a pretty crappy model of Phong!...Get it? Phong Shading Phong?...
...
...
As in Phong from ReBoot?
...
...
I did say it was a horrible joke.