Re: [Algorithms] Re: Lightmap Terrain (dynamic range)

[Tom H. <to...@3d...>]

At 02:52 PM 8/25/2000, you wrote:
>Bottomline: the problem is exactly the same for cinema and video, so if
>you're happy with the "sun impression" that you get on films, there is
>no physical limitation with your CRT display that will prevent you from
>getting teh same with 3D games.

Very true. I for one don't really want a CRT capable of emitting energy 
ranges equal to real life. I mean, staring into the sun hurts :)

I did a lot of work on dynamic range management for digital cameras a 
little while back. The techniques I used where based on pixel statistics 
(histograms) of the luminance values of the image in a feedback system 
(calc statistics for current frame, adjust next frames exposure time and 
digital gains to compensate). I came up with a pretty sweet system that 
would converge on an answer in very few frames, and was very resistant to 
oscillations (even with the optimizations required to be workable in cheap 
hardware).

Adjusting gamma values will not give you the desired result however. A 
couple of reasons:
1. You'll get banding as you stretch or squish the range by any significant 
amount. Applying any gamma value other than 1.0 (identity) throws away bits 
of color resolution.
2. Going from inside to outside is a HUGE range shift ... on the order of 
~200 Lux for a normally lit office inside to ~5000 lux for outside at noon 
in the summer on a clear day. Not something that will scale well with just 
a gamma change.

My biggest problem is finding a good way to extract intensity information 
from the scene. The simplest method is to read the pixels back from the 
frame, calculate the statistics I've mentioned above and scale the 
lightmaps accordingly (which means everything gets a light map ... even the 
sky). Of course, reading back the frame buffer into system memory to 
perform the calculation is slow at best.

Another possibility would be to attach intensity information to surfaces 
and accumulate the statistics on those as they're added to the scene. 
Unfortunately this doesn't give you very good information about occlusion.

Another idea I just had would be to create low-res imposters for the items 
in the scene (people and cars would be cubes, etc) and render these with 
software into an intensity image with proper occlusion tests (zbuffer ... 
span buffer .. whatever). The result could then be used to get a coarse 
approximation of the scene intensity. With something like a span buffer you 
would never need to generate the image itself as you could calculate pixel 
statistics from the spans and still have proper occlusion.

Tom