OT: lightmaps and lighting moveable objects

Started by
6 comments, last by zedzeek 17 years, 8 months ago
Not strickly a GL question. Let's say my map has a lightmap applied to it. I am moving around my scene. My character goes into a shadow area. How to know this happened? Should I do a intersection test to see on which polygon the character is, find the st coordinate and sample the texture in RAM, apply the color to my character? What if part of the character is in shadow and part in light? I'm thinking perhaps projecting a lightmap into the scene is one way. I could project the same lightmap onto the character but this isn't practical.
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Advertisement
You may want to checkout the concept of 'light volumes' or 'local illumination data'.

Basically you divide the map into a uniform grid of volumes and calculate the average light 'amount' that enters each volume in the grid. Quake3 divides maps into 64x64x128 volumes. They also store other stuff in the volumes such as direction and color.

In your game, you can quickly lookup which volume your entity is in and apply the appropriate lighting value or material to shade the entity.

Light volumes

Quake 3 Map format

Good Luck.
0xa0000000
That's interesting but you need to figure out in which boxes your moveable object is in and your light volume may consume lots of additional RAM. Thanks for the heads up.
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Every polygon has a lightmap.
Find out on which polygons you character is standing (you should have this information from you collision detection system anyways) and project these lightmaps onto your character.
I'm almost sure that's what Doom 3 does.
Quote:Original post by V-man
That's interesting but you need to figure out in which boxes your moveable object is in and your light volume may consume lots of additional RAM. Thanks for the heads up.

That true, is basically a trade-off between using more CPU time or more RAM.

Lets say you have a level 32k x 32k x 4k. You choose a volume size of 128x128x64.
Each volume hold a single value(byte) from 0(nolight) to 255(fullbrightness). Total memory consumed = 250*250*63 = ~4MB. With compression probably around 1MB.

To find the volume a movable object is in becomes a simple lookup.
For an object at (512.0 4.34 1023.43):
Calculate volume index:
xindex = 512 /128 = 4
yindex = 4 /128 = 0
zindex = 1023/64 = 16
Access value:
brightness = volume_light[4][0][16];
Then of course you would interpolate between the previous brightness to get a smooth transitions.
0xa0000000
It's a good idea but it's not suitable for a large areas. Light volumes are really 3D textures and you can't have too many of them.

I think you need to have a volume per room or per reasonable area to have a good effect. I don't know enough about Q3, but it probably stores a few per bsp.

"Every polygon has a lightmap.
Find out on which polygons you character is standing (you should have this information from you collision detection system anyways) and project these lightmaps onto your character."

I could project or perhaps I'll flag the object as light is hitting it and at the same time have light effect it to have a selfshadowing effect.

I'm almost tempted to do dynamic lights all around, but they consume too much juice :)
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Quote:Original post by V-man
It's a good idea but it's not suitable for a large areas. Light volumes are really 3D textures and you can't have too many of them.

I think you need to have a volume per room or per reasonable area to have a good effect. I don't know enough about Q3, but it probably stores a few per bsp.
It's already been stated that each Q3 light volume has dimensions of 64x64x128. Unless I've miscalculated, the larger Q3 maps have as many as 50,000 light volumes, which is certainly more than a 'few per bsp'.

Each cell takes 8 bytes, so you can do the math as far as memory is concerned. Whether the memory cost is a problem depends on the platform. As for efficiency, calculating the lighting for an entity is a simple grid lookup followed by trilinear interpolation of a few values, an insignificant expense on a modern PC or console.
Quote:Every polygon has a lightmap.
Find out on which polygons you character is standing (you should have this information from you collision detection system anyways) and project these lightmaps onto your character.

its gonna look wrong

im pretty sure quake3 etc do what ack Sotac saiz
"Basically you divide the map into a uniform grid of volumes and calculate the average light 'amount' that enters each volume in the grid. Quake3 divides maps into 64x64x128 volumes. They also store other stuff in the volumes such as direction and color."

"it's a good idea but it's not suitable for a large areas. Light volumes are really 3D textures and you can't have too many of them."
128x64x128 = 1 mb ( i byte per color, u could prolly get away with 1/2byte even) ie not much, also if this game is outdoors ild have the y array being a variable number, ie why store 64 pieces of the same data.

This topic is closed to new replies.

Advertisement