🔒 Locked

SH Lightmapping

Started by cPugh Jun 7, 2010 at 8:07 AM 5 replies 8k views

Original Post

Jun 7, 2010 at 8:07 AM

I'm currently doing some research into SH lighting in its various forms, in particular PRT. While looking, I found this article, The Lighting and Material of Halo 3, where the author discusses the use of SH lighting in Halo 3. They talk about how they use a technique similar to lightmapping for level geometry, except instead of varying a final radiance color in a texture, they store SH coefficients for the incoming radiance, based on a GI solver, and use this information per-pixel, together with the normal map information, to calculate diffuse lighting. However, maybe its lack of sleep,or maybe I'm misunderstanding the approach here, but I'm failing to see the advantage of doing things this way compared to standard lightmapping. If the incoming light is precomputed (static) and diffuse (no view dependence), and the level geometry and the normal maps on that geometry are also static, the final diffuse lighting value should also be static, and should be able to be captured by a standard lightmap with less computational hassle at runtime. SH Lightmaps also take up a ton more memory per-texel depending on the number of coefficients you're using. Am I missing something?

Link: http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf

jcabeleira

126

jcabeleira

Jun 7, 2010 at 10:41 AM

Storing the lightmaps as spherical Harmonics allow you to apply bump-mapping effects to the lightmapping. This is similar to the 3-axis radiosity representation used by Valve on their source engine.

n00body

Jun 7, 2010 at 1:02 PM

You can also have dynamic objects use their position over the SH lightmap to sample it, and get lighting from all around them at that point.

wpyax

Jun 7, 2010 at 9:23 PM

dynamic object??? how can do that? is it having any paper?

Hodgman

Mod

5,991

Hodgman

Jun 7, 2010 at 10:12 PM

Quote:
Original post by cPugh
If the incoming light is precomputed (static) and diffuse (no view dependence), and the level geometry and the normal maps on that geometry are also static, the final diffuse lighting value should also be static, and should be able to be captured by a standard lightmap with less computational hassle at runtime

The problem is that the normal maps are usually much higher resolution (texels per game-meter) than the light-maps, so if you took the normal-maps into account when baking the light-maps, you'd lose a lot of detail.
With SH-lightmaps (and other multi-direction light-map approaches, like UE3/HL2) you can use a low-resolution light-map, and still have highly detailed normal maps producing the final result.

Viik

Jun 8, 2010 at 11:13 AM

Quote:
dynamic object??? how can do that? is it having any paper?

Check Froblins paper by Ati.

to cPugh
You can try going even further. Bungie was storing lightmaps and sun\sky light was static, you can try to store PRT operator instead, that would require more than 4 coeeficients of SH to give nice shadows, but potentially you could dynamically change lighting, aka dynamic sun\sky light.
Btw, if you don't care about having interreflection in PRT operator then you don't need to store coefficients for RGB separately, you will need only one single channel.

cPugh

Author

cPugh

Jun 8, 2010 at 9:56 PM

Thanks to everyone who replied.

Quote:
Original post by Hodgman
Quote:
Original post by cPugh
If the incoming light is precomputed (static) and diffuse (no view dependence), and the level geometry and the normal maps on that geometry are also static, the final diffuse lighting value should also be static, and should be able to be captured by a standard lightmap with less computational hassle at runtime
The problem is that the normal maps are usually much higher resolution (texels per game-meter) than the light-maps, so if you took the normal-maps into account when baking the light-maps, you'd lose a lot of detail.
With SH-lightmaps (and other multi-direction light-map approaches, like UE3/HL2) you can use a low-resolution light-map, and still have highly detailed normal maps producing the final result.

I had thought of this - the normal map is much higher resolution than a typical lightmap, but I intuited that this might be cancelled out by the significant storage costs of storing 9 floating point coefficients for an irradiance environment map (versus just upping the resolution of the lightmap). However, it makes sense that an SH lightmap can be *significantly* lower resolution than the normal map.

Quote:

You can also have dynamic objects use their position over the SH lightmap to sample it, and get lighting from all around them at that point.

This is a nice advantage too, although the paper states that they used a uniform volume of SH lighting environments for dynamic objects in their engine. It seems that there's something of a quality/memory tradeoff there.

Quote:

You can try going even further. Bungie was storing lightmaps and sun\sky light was static, you can try to store PRT operator instead, that would require more than 4 coeeficients of SH to give nice shadows, but potentially you could dynamically change lighting, aka dynamic sun\sky light.
Btw, if you don't care about having interreflection in PRT operator then you don't need to store coefficients for RGB separately, you will need only one single channel.

Actually, this is part of what I'm working on currently; I'm using high quality diffuse PRT to augment the direct lighting with global illumination effects that can work under dynamic lighting. I thought this is what Halo was doing to begin with, so I found it really interesting that they were actually just storing a static lighting environment per texel.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.