Calculating how visible an object is in a 3D-scene for use in game logic/AI

Question

I am starting a game project which will allow characters to hide in dark areas. Hiding in a dark corner should make it harder for other characters to see you.

What I need is a way to calculate how the lighting conditions are where the character is located.

The ideal would be to have a

double getLightFactor(GameCharacter observer, GameCharacter target)

since I suppose there could be lighting conditions where light falls so that different sides of the target is hit by different amounts of lights. But I would gladly settle for

double getLightFactor(GameCharacter target)

to get the light for a specific character regardless of where you are watching from or even

double getLightFactor(int x, int z)

to just get the light at a specific map point in the terrain.

The method need to take into account that lighting conditions may change during gameplay, but since it is turn based some heavy calculations could be allowed. I intend to make it possible to use flashlights so they need to be taken into account as well (but they could be modeled and handled separately).

I will be using Ogre3d to handle my scene, but I will happily accept generic solutions or even solutions for other engines (my choice of engine is not carved in stone).

Ideas, papers or really anything relevant is very welcome!

Answer 1

You could just render the scene from the viewpoint of the observer to an offscreen buffer (even in a rather low resolution) taking into account the current light settings. Then you could calculate a mean luminosity value around the middle of the target character.

I do not know about the Ogre3d engine, but this should be a rather generic way to handle your problem (it's just rendering the scene from a different viewpoint after all...)

Answer 2

Oh boy. This depends a lot on the engine. I can tell you now that you want the second option.

How does lighting work? Is it dynamic or static? Let's assume it's a combination of both.

For static lighting, check the lightmap nearby. It's either vertex based or a texture, either way, you can sample it at a few points nearby and average them. Look at how the engine computes the lighting for models, dig into the graphics code and see where the data actually comes from, you can use the same source. Some games have volumetric lighting information, Quake 2 does this on a per-leaf basis in the BSP tree (easy to check) and Quake 3 has volumetric textures (also easy to check).

Then you'll need to add the dynamic lights. One way you can do this is by shooting rays from the player (probably a few different rays to be sure, from different parts of the player) towards the light source. Count how many are hit and add a little bit to your number for each one, depending on how far the light is. All decent game engines have a procedure for "shoot ray and see what it hits", it's how AIs do line of sight and how you figure out what bullets hit and what happens when you run into the wall. Don't shoot too many rays too far because it could be slow.

You wouldn't have to recompute this value too often, you could do it whenever a new light source is created and then every second or so.

Answer 3

Depending the complexity of the environment, you could cheat and use a 2D lightmap overlayed on the terrain. Each cell would have a light intensity value based on the nearby light sources. It would be fast to calculate even for moving objects, and fast to access to determine the "darkness" of a location.

You may have to "stamp" shapes onto it using simple box or circle algorithms depending on the type of lights you have.