Question

I’ve been wanting to write it for some time now… as a project for the university, I’ve written (with a friend) a game that needed good explosions & particles effects. we’ve encountered some problems, which we solved quite elegantly (I think), and I’d like to share the knowledge.

OK then, so we found this tutorial: Make a Particle Explosion Effect which seemed easy enough to implement using Java with JOGL. before I’ll answer as to how exactly we implemented this tutorial, I’ll explain how rendering is done:

Camera: is just an orthonormal basis which basically means it contains 3 normalized orthogonal vectors, and a 4th vector representing the camera position. rendering is done using gluLookAt:

glu.gluLookAt(cam.getPosition().getX(), cam.getPosition().getY(), cam.getPosition().getZ(), 
              cam.getZ_Vector().getX(), cam.getZ_Vector().getY(), cam.getZ_Vector().getZ(), 
              cam.getY_Vector().getX(), cam.getY_Vector().getY(), cam.getY_Vector().getZ());

such that the camera’s z vector is actually the target, the y vector is the “up” vector, and position is, well… the position.

so (if to put it in a question style), how to implement a good particles effect?

P.S: all the code samples and in-game screenshots (both in answer & question) are taken from the game, which is hosted here: Astroid Shooter

Answer 1

OK then, lets look at how we first approach the implementation of the particles: we had an abstract class Sprite which represented a single particle:

protected void draw(GLAutoDrawable gLDrawable) {
    // each sprite has a different blending function.
    changeBlendingFunc(gLDrawable);

    // getting the quad as an array of length 4, containing vectors
    Vector[] bb = getQuadBillboard();
    GL gl = gLDrawable.getGL();

    // getting the texture
    getTexture().bind();

    // getting the colors
    float[] rgba = getRGBA();
    gl.glColor4f(rgba[0],rgba[1],rgba[2],rgba[3]);

    //draw the sprite on the computed quad
    gl.glBegin(GL.GL_QUADS);
    gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex3d(bb[0].x, bb[0].y, bb[0].z);
    gl.glTexCoord2f(1.0f, 0.0f); gl.glVertex3d(bb[1].x, bb[1].y, bb[1].z);
    gl.glTexCoord2f(1.0f, 1.0f); gl.glVertex3d(bb[2].x, bb[2].y, bb[2].z);
    gl.glTexCoord2f(0.0f, 1.0f); gl.glVertex3d(bb[3].x, bb[3].y, bb[3].z);
    gl.glEnd();
}

we’ve most of the method calls are pretty much understandable here, no surprises. the rendering is quite simple. on the display method, we first draw all the opaque objects, then, we take all the Sprites and, sort them (square distance from camera), then draw the particles, such that further away from the camera is drawn first. but the real thing we have to look deeper into here is the method getQuadBillboard. we can understand that each particle has to “sit” on a plane that is perpendicular to the camera position, like here:

the way to compute a perpendicular plane like that is not hard:

1. substruct particle position from camera position to get a vector that is perpendicular to the plane, and normalize it, so it can be used as a normal for the plane. now a plane is defined tightly by a normal and position, which we now have (particle position is a point that the plane goes through)

2. compute the “height” of the quad, by normalizing the projection of the camera’s Y vector on the plane. you can get the projected vector by computing: H = cam.Y - normal * (cam.Y dot normal)

3. create the “width” of the quad, by computing W = H cross normal

4. return the 4 points / vectors: {position+H+W,position+H-W,position-H-W,position-H+W}

but not all sprites acts like that, some are not perpendicular. for instance, the shockwave ring sprite, or the flying sparks/smoke trails:

so each sprite had to give it’s own unique “billboard”.BTW, the computation of the smoke trails & flying sprites sparks was a bit of a challenge as well. we’ve created another abstract class, we called it: LineSprite. i’ll skip the explanations here, you can see the code in here: LineSprite.

well, this first try was nice, but there was an unexpected problem. here’s a screenshot that illustrates the problem:

as you can see, the sprites intersects with each other, so if we look at 2 sprites that intersects, part of the 1st sprite is behind the 2nd sprite, and another part of it, is infront the 2nd sprite, which resulted in some weird rendering, where the lines of the intersection are visible. note, that even if we disabled glDepthMask, when rendering the particles, the result would still have the lines of intersection visible, because of the different blending that takes place in each sprite. so we had to somehow make the sprites to not intersect. the idea we had was really cool.

you know all these really cool 3D street art?
here’s an image that emphasizes the idea:

we thought the idea could be implemented in our game, so the sprites won’t intersect each other. here’s an image to illustrate the idea:

basically, we made all the sprites to be on parallel planes, so no intersection could take place. and it did not effected the visible data, since it stayed the same. from every other angle, it would look streched, but from the camera point of view, it still looked great. so for the implementation:

when getting 4 vectors representing a quad billboard, and the position of the particle, we need to output a new set of 4 vectors that represents the original quad billboard. the idea of how to do this, is explained great in here: Intersection of a plane and a line. we have the “line” which is defined by the camera position, and each of the 4 vectors. we have the plane, since we could use our camera Z vector as the normal, and the position of the particle. also, a small change would be in the comparison function for sorting the sprites. it should now use the homogeneous matrix, which is defined by our camera orthonormal basis, and actually, the computation is as easy as computing: cam.getZ_Vector().getX()*pos.getX() + cam.getZ_Vector().getY()*pos.getY() + cam.getZ_Vector().getZ()*pos.getZ();. one more thing we should notice, is that if a particle is out of the viewing angle of the camera, i.e. behind the camera, we don’t want to see it, and especially, we don’t want to compute it’s projection (could result in some very weird and psychedelic effects…).
and all is left is to show the final Sprite class

the result is quite nice:

hope it helps, would love to get your comments on this “article” (or on the game :}, which you can explore, fork, and use however you want…)