Once in a while you might be looking to implement a certain effect or feature in your game and at the risk of being called a “google programmer”, you search around and find a related paper or article that describes a method of achieving this. I was recently wanting to do just that: implement a day / night cycle with the associated atmospheric scattering during sunrise and sunset. This process, that is going from the theory/paper or even a piece of code to having a working algorithm that functions in your particular application, can quickly become cumbersome and “fiddly” for lack of a better term. Here are a few tips that might help with doing this more effectively:
Know What You Want, and Consider the Alternatives
More often than not, a number of different people have thought about and tried to solve the problem you are interested in. And a number of solutions might be available out there which will range in complexity. But before you can decide which direction to go in, you must decide what it is you are really after. Are you looking for a physically accurate solution? Or something that simply looks good? Are you after something that is changing during the game, or is more static and can be pre-calculated? What sort of performance characteristics are you after? What are you hardware limitations? Of course, I’m not excluding the option of actually trying out a couple of different solutions before settling with one, assuming you have the time.
Understand the Theory
When I’m reading an article that comes with sample code, or even pseudo code, there is a tendency to skip all the way to that section. I mean seriously, between staring at something like this:
and a block of C++ code, I know which I’d rather go for. But I cannot emphasize enough how important it is to understand the theory and the concept when trying to implement it yourself. Not only does this help you understand the code and the different variables involved better, it’ll help you modify and improve the algorithm for your needs in a more predictable and less trial-and-error manner. Besides, it makes you feel a certain ownership and satisfaction in the implementation that you would not get from simply massaging the code into your own project.
Be Sure of Your Assumptions
Often times the solutions you come across will have slightly different initial assumptions than those you have in your game. In my case, the solutions I came across mostly assumed that the camera was free to move in and out of the atmosphere. However I was looking to render the sky-dome at a fixed distance from the camera always. Identifying the assumptions in the beginning will not only save you a lot of debugging later on, it will help you with potential optimizations.
Hold Onto Your Pen
Call me old fashioned, but when I’m working on an algorithm, be it something brand new or an adoption of someone else’s work, I need to have a pen and plenty of paper next to me. There are only so many numbers and shapes I can keep in my head. So whether I’m going through an article to understand an algorithm, or stepping through my code to find out where I’ve gone wrong, it really helps to draw things out on paper. You’ll be surprised how many times something that seems completely correct as code and in your head, will obviously be incorrect when drawn out on paper. Additionally it can actually be quite fun solving the occasional trig or algebraic equation by hand!
Leave Optimization for Later
Often when you find a piece of code associated with an algorithm, the original author has optimized the heck out of it. I generally find it useful to implement it as verbosely, and as closely linked to the original equations as possible. This makes the job of hunting bugs later more easy, and it helps with understanding the theory as I mentioned earlier. Once everything is working, optimizations will become the easy part (…fine, optimization is not always easy…)
Respect the Source
This is not really a tip for implementation, but more of a request. If you are going to share your implementation of somebody else’s work, and especially if you are going be making money from it, say as a plug-in for an engine (assuming there are no legal concerns to begin with), please have the courtesy to give credit to the owner of the work. That’s All :)
Oh, and just so I’m true to my last comment: the particular approach I’m taking with atmospheric scattering is based on this article by Sean O’Neil