Rendering of various phenomena, Article 1: Lens Flares
Greetings!
This is the first in what I hope will be a series of articles explaining how to render various effects in real-time, in a way that might be useful for those interested in creating their own game.
I make the following assumptions:
You know C well enough to follow what's going on in a block of code. I comment everything quite heavily, and I try to use constructs that will map well to most other common languages, but the nuts and bolts are all in C.
You know, or at least are aware of, OpenGL to some degree (fortunately, the designers of the library saw fit to name every function for what it actually does, so if you don't know it, you'll still be able to follow along).
You know how to edit, compile and link a program on your machine.
Additionally, for portability reasons, I rely on the Allegro library for basic things like loading images, interfacing with the windowing system and other OS-specific work. When possible, though, I'll keep to non-Allegro specific code, so people using things like SDL or working directly with their chosen OS' graphics functionality should still find this useful. I've enclosed a Windows binary, but this should compile on any machine.
Disclaimer: using this code or running the binary enclosed could ruin your machine, tarnish your reputation and cause people to make disparaging remarks about your parents, and you should treat this as you would any code found on the internet - however, it's never exhibited this behaviour during coding or testing. Additionally, I don't claim that this is the only way, or even the best way to do a specific task - I'm merely documenting what has worked for me in hopes that others that have the same questions I did when I started will have a base from which to work.
In today's article, I discuss a fairly lightweight method of rendering lens flares and provide a well-commented working implementation. Although the sample program relies on OpenGL to do its dirty work, the method used here would work for any rendering API in which a projection matrix is kept and can be retrieved later, and in which a z-buffer is available.
How it works:
Although the function in the sample program grew to be a 200-line behemoth when I attempted to make both the source and the output prettier, it's really quite simple. For the light source or point you'd like to add a lens flare to:
Find or retrieve the current projection matrix.
Find or retrieve the boundaries of the current window.
Multiply the coordinates of your point by the inverse of the projection matrix obtained in step one.
If the multiplied point is inside the window bounds, check the z-buffer at that location, to see if the point is occluded.
If it's not, render a textured, alpha-blended rectangle at the multiplied point.
???
Profit!
And that's about it. (I added some secondary flares to simulate the complex optics of a real camera, but, as you'll see, this is trivially done by simply dividing the negative of the distance between where the light source is in the viewport and the centre of the viewport by a constant and placing another textured quad at the resulting point.) For specifics, you'll want to look at the function posted below that actually does all the heavy lifting, and run the program (if your machine allows it) to see the results.
Controls:
UP ARROW moves camera up
DOWN ARROW moves camera down
LEFT ARROW rotates camera left
RIGHT ARROW rotates camera right
Bugs:
The trouble with this method, at least as implemented here, is that, because gluProject doesn't take into account the near or far planes of the frustum when multiplying the coordinates of a point passed to it, it's possible something could be inside the double-pyramid the projection matrix describes, causing the lens flare to appear when the camera is facing exactly 180 degrees away from it, too.
It would be possible to test if the light source getting the flare were behind the camera, preventing this case, but I didn't do this as it'd add to the complexity of the demo program. In the common case for most games, though, some sort of ground geometry will usually prevent the shinethrough of, say, the sun from happening by placing something in the z-buffer ahead of the false sun position.
