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

[Ralf S. <rap...@ra...>]

yo may also read this article from hugo elias:

http://freespace.virgin.net/hugo.elias/graphics/x_posure.htm

- ralf

| 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

| _______________________________________________
| GDAlgorithms-list mailing list
| GDA...@li...
| http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list