Jump to content
  • Advertisement
Sign in to follow this  
V-man

OT: lightmaps and lighting moveable objects

This topic is 4402 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!