Contents  Introduction  Radiosity Mapping  Dynamic Light  Source Radiosity  Dynamic Object  to Static Object  Radiosity  Conclusion  Printable version     The Series  Part I  Part II

Dynamic Light Source Radiosity

So, now we have our happy little dynamic objects running around with radiosity, and everything is great, right? Well, no. There is still another problem. That problem is dynamic light sources.

In most games, the radiosity is pre-calculated for the level (i.e. walls, floors, ceilings, stair cases, anything that never moves), and that works fine as long as there are no moving light sources. But guess what, there are moving light sources! Whenever you fire a rocket, you are creating a moving light source. And whenever you shoot your gun, it creates a flash of light coming from where you are. So, that messes up the pre-calculated radiosity, because to have it be accurate, you have to recalculate the radiosity in one way or another.

So, now the question is: how do we re-calculate the radiosity fast enough to do in real time? And this second method of mine is the answer.

The method is actually quite simple, really. All you have to do is pre-store contribution levels (which I'll explain in a second), and use thresholds to determine whether the radiosity has to be updated.

So, let's consider a typical scene... perhaps a room. And let's say that each wall is a different color (red, green, blue, and yellow). So, with traditional methods, the radiosity would be pre-calculated, with the walls subdivided into multiple squares, each of which has a separate lighting value. Now, what happens when a dynamic light source comes waltzing in? Well, you could recalculate all of the radiosity of the scene, re-subdividing everything, and re-calculating all of the distances and such. But that would take forever!

Instead, how about we keep the subdivision information, and only recalculate the distances between them? Well, those distance calculations would be a pain also, so why not maintain all of the distances in an information tree? Well, it would still take a while to calculate how much light was radiated from each of the squares to each other one. So, why don't we just maintain an information tree of how much light every single square contributes to each other one? Then all we would have to do would be to find the regular lighting value of each square (i.e. the one before radiosity), and then pump those lighting values through a weighting algorithm, using the pre-stored contribution levels as the weights for each respective square.

But there's still something not right with this. First of all, with a tree that huge, it would take quite a bit of time to find the correct contribution information between two squares no matter what sorting algorithm you used! So, we have to find some way to cut this list down. There is one easy way to do this: thresh-holds. When you are pre-calculating the light contribution levels for each square, only record ones that are above a certain level (i.e. the ones that actually have some significance), then any light contribution that won't make a difference anyway won't be stored in the tree!

But even with all of this, it would still be extremely slow to do all of this dynamically. So, guess what, we use thresholds once again! Except, in this case, we use them in real-time, not just to eliminate useless information from the pre-calculated tree.

The basic idea is that we don't want all of our pre-calculated radiosity to go to waste (and by radiosity, I mean the actual lighting values, not the contribution levels). So, what we do is we, by default, render the room with the pre-calculated lighting values.

Then when a dynamic light source comes waltzing along, you check to see how much it affects each square. Each square will have a thresh hold of change, and only if it's lighting is changed more then the amount allowed by the thresh hold from its pre-calculated lighting values will the program actually take the time to re-calculate the radiosity for the other squares it effects.

Of course, there is one little detail through all of this that I have neglected to mention: the pre-calculated radiosity in games is not stored as squares as in non-real time rendering engines, it is stored as light maps (which are like texture maps, except with lighting values). So that puts our entire idea to pot, right? Wrong. What we can do is place un-rendered vertices on the surfaces of walls and such, which correspond to pixels on the light maps. Each vertex will have the contribution information, and the thresholds as to whether or not the radiosity is re-calculated. So, when you light the walls with a dynamic light source, you give the vertices those light values, and proceed as I described, except that if the radiosity does need to be re-calculated, you modify the light map by interpolating the lighting values from the vertices across the corresponding pixels of the light map.

As for choosing where to place the vertices, you should probably place more vertices in areas of high radiosity (i.e. where there is a high probability that there will be significant radiosity change, such as corners, where there are two surfaces very close to each other).

Next : Dynamic Object to Static Object Radiosity