light maps

Started by
5 comments, last by phaelax 19 years, 11 months ago
I read that to apply a light map to an image, you multiply them together. new image = light map * texture P = L * T p.r=l.r * t.r p.g=l.g * t.g p.b=l.b * t.b But each color value can only be 0-255. So I''m a little confused on how this would work.
Advertisement
It makes sense if you think of the red green and blue components as values between 0 and 1 (0 meaning none of that component, and 1 meaning full saturation). Then if the lightmap at a certain pixel has a value of .5, then the texture at that point will only appear half as bright.

Color values are not limited to 0-255, it actually depends on the number of bits allocated to each color channel. But thinking of color as a real value between 0 and 1 works no matter how many bits of resolution are being used.
generating lightmaps has always been something I have been curious about. It at first seems incredibly hard, but maybe it isn''t so bad. I dont'' know if this should go in another forum (if it should then I will move it or the mod can).

But basically, as I understand it, the algorithm is like this:

-Pick a size for a texel (dont'' even know if a texel is of finite size or not, my understanding is that a texel is kind of like a pixel, except it is a finite size or ''real estate'' of the texture)
-Trace from the light source to the texel
-If there is no collision then apply the light values to the texel value (although I''m not even sure how you do this, does this just mean that you generate a second texture, and then pass this to the second texture unit on your GPU so it can calculate it real time in case the same base texture needs to be reused ?)

Why don't alcoholics make good calculus teachers?Because they don't know their limits!Oh come on, Newton wasn't THAT smart...
So really, I''m just averaging the two numbers.

p.r = (l.r * t.r) / 255
Light maps are also, perhaps more accurately, known as dark maps. They essentially take the color of the object and darken it. This is easy to see with a greyscale light/dark map. Say you apply a nice brick texture to a wall, with all its red/green/blues on the pixels. Now, lets say you have a greyscape light map that is 100% white, every pixel in the light map is (1, 1, 1). Multiply (1, 1, 1) by the (r, g, b) of the texture and you get....(r, g, b). No change. The thing is 100% illuminated. But, say the dark map is all black, all (0, 0, 0) pixels. When you multiply that by the texture you get (0, 0, 0). The object turns black. Now say you have a greyscale in between, say (0.5, 0.5, 0.5). Multiply and you get (0.5 * r, 0.5 * g, 0.5 * b) for all the pixels. The object is darkened by half. So, the greyscale dark map really just causes the pixels in the object to be something between (0, 0, 0) and (r, g, b). If it does anything to a pixel, it darkens it from the texture (r, g, b) color. If your dark map is black around the edges with a smooth transition to white inside a spotlight, then your object will be black around the edges (fully darkened by the light/dark map) and (r, g, b) in the middle (not at all darkened by the light/dark map). This is how a light/dark map works.

Usually, light/dark maps are greyscale. Reason being, that is often all that is needed, and greyscale images can be 8-bit instead of 24, 32, or higher bit depth. Pretty easy to understand from above. But, if your light/dark map is not greyscale for some reason, you can get some interesting effects. For example, you could simulate a spotlight that is an arbitrary color. Or you could simulate a slide projector as a light source. Cool stuff!

Graham Rhodes
Principal Scientist
Applied Research Associates, Inc.
Graham Rhodes Moderator, Math & Physics forum @ gamedev.net
Oh, I should have mentioned that those 0 - 255 color values are integer values. Forget that. Computer graphics algorithms, including light/dark maps really are floating point-based not integer-based, with r, g, and b ranging from 0.0 to 1.0, not 0 to 255. This is quite an important distinction, since if they were 0-255, then you''d get overflow right away and the light map wouldn''t have the darkening effect I mentioned!

That said, there is the concept of high-dynamic-range (HDR) rendering in which the range of colors can extend beyond 0.0 to 1.0. Any color value > 1.0 is called overbright. I won''t go into it further, but you can read some things over at Paul Debevec''s site:

Paul Debevec''s Home Page

Also, Peter Pike Sloan and others at Microsoft Research have also done very cool breakthrough work in the area of HDR rendering.

Graham Rhodes
Principal Scientist
Applied Research Associates, Inc.
Graham Rhodes Moderator, Math & Physics forum @ gamedev.net
thx for help. and grhodes, thats an interesting website.

This topic is closed to new replies.

Advertisement