Re: [Algorithms] Some question about "Lighting and Material ofHalo3" and "Lightmap compression in Halo 3"

[Sébastien L. <seb...@do...>]

I think halo wanted to store direct + indirect lighting in their SH lightmap, so they require L2 coeff , (if only indirect lighting was store L1 coeff will be sufficient)

As RGB * 9 coeff = 27 float represent too much data to store in texture, they compress by converting the L2 coeff by L1 coeff + a directional light RGB

 

You can find a similar conversion in "Stupid spherical harmonics tricks" section "Extracting Conventional Lights from SH"

where an ambient light + directional light is extracted from SH coefficient.

 

The difference here is that instead of using a conventional ambient light, the ambient light is the remaining L1 SH coefficient after removing the contribution of

the directional light in the optimal linear direction (at least, I suppose they do that).

You can find explanation and code of this in this paper: http://ati.amd.com/developer/SIGGRAPH08/Chapter03-SBOT-March_of_The_Froblins.pdf

 

So to sum up, they get their L2 coeff, they calc the dominant light intensity RGB from them,

they extract this dominant light intensity RGB from L2 coeff and discard quadratic coefficient to only conserve L1 coeff.

So you get remaining L1 coeff RGB = 12 float and HDR dominant RGB = 3 float, this result in 15 float

instead of the 27 initially which they claim of similar quality.

 

At runtime, mesh are lighted by a RGB directional light as usual, and the L1 contribution is added to the diffuse part of the lighting.

If you not compress, you light your mesh with L2 coeff directly (for the diffuse part).

 

The point here is that they store the intensity RGB, they don't need to store "optimal linear" direction as it can be retrieve from L1 SH coeff. 

 (at least, this is my question, if L1 coeff are remaining SH light, we won't get the same "optimal linear" direction,  so I suppose they store the L1 SH light, and remove dominant RGB contribution in the shader, any though about this ?)

 

Of course, all this is  just guess.

Peter ?

 

Lagarde Sébastien

 

 

De : Sam Martin [mailto:sam...@ge...] 
Envoyé : vendredi 5 février 2010 17:46
À : Game Development Algorithms
Objet : Re: [Algorithms] Some question about "Lighting and Material ofHalo3" and "Lightmap compression in Halo 3"

 

Hi Peter,

 

Do you have a link to a paper/slides explaining why they store an "optimal linear" direction separately? I'm not sure why you wouldn't want to just use the L1 coeffs as a vector?

 

I couldn't find an explanation in the links below. 

 

Thanks,

Sam

 

From: Peter-Pike Sloan [mailto:pet...@ho...] 
Sent: 01 February 2010 21:45
To: gda...@li...
Subject: Re: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3"

 

Hi,

 

I believe the source of confusion is that in this equation (5) things are expressed in the local coordinate frame, the fact that they show 3 coefficients implies they are using quadratic SH (so when rotated into the local frame and integrated against a clamped cosine function you only need the 3 ZH coefficients.)  The general case (where you don't know the coordinate frame, or you want to evaluate for any normal) requires all 9 coefficients.

I think the "5*3" comes from the compression mentioned in Hao's slides (linear SH + RGB for directional light in "optimal linear" direction.  Which is 5*3 scalars.)

 

The compression work is Wang et al, I think Yaohua's slides are more indicative of what was actually used...

 

Peter-Pike Sloan

 

________________________________

Date: Fri, 29 Jan 2010 16:28:57 +0100
From: seb...@do...
To: gda...@li...
Subject: [Algorithms] Some question about "Lighting and Material of Halo3" and "Lightmap compression in Halo 3"

Hello all, 

 

I tried to contact the author of this two (now old) paper, without success,:

"Lighting and Material of Halo 3" published at siggraph 2008 (http://ati.amd.com/developer/SIGGRAPH08/Chapter01-Chen-Lighting_and_Material_of_Halo3.pdf)

and GDC 2008 conference "Lightmap compression in Halo 3" (http://toomuchlogic.com/Lightmap_Compression_2008_02_22.pdf)

so I will ask some question to the list, if anyone is interested by the subject and has better understanding of math than me :)

 

1. "Lighting and Material of Halo 3"  About equation (5) the diffuse reflectance using SH basis

the diffuse reflectance using SH basis is : k_d R_d Sum Lambda_i A_i

A_i is the projection of the cosine lobe in SH, and as it is radially symetric.

all coefficient with m != 0 are 0.

After that the author give the first three term of A_i.

I wondering how many band are use for this calculation  ? (order 3, 4 or more ?)

 

I read from "Stupid spherical harmonics tricks" from Perter Pike sloan (http://www.ppsloan.org/publications/StupidSH36.pdf)

that order 3 SH is sufficient for approximate light source

but for HDR light sources he recommand order 5.

As order 4 is 0 (From paper http://www.eecs.berkeley.edu/~ravir/lighting.pdf I get the formula for A_i)

This mean 4 coefficient to store by color channel.

As I am pretty sure the author store  HDR data, can someone lighten me ?

 

2. About texture storage (which are deduced from above statement)

 

I try to figure out how are encoded the incident radiance in their SHLightmap.

>From GDC 2008 conference "Lightmap compression in Halo 3" I can read that the author need to

store for each texel a vector of 5 * 3 float values.

I don't figure what are the values exactly.

 

My assumption is that "3" is for each channel color RGB,

But I can't figure what's the 5 is ?

Are they 5 first band of SH order like I suppose above (but as I said, we only need 4 coefficient in this case)

or maybe order 6 ?

 

In this same paper later I found:

A. Two DXT5 texture for each SH coefficient channel (HDR, positive/negative)

And

B. Each band of the SH coefficients (RGB) are converted to Luvw space

 

I suppose that Luvw space is what is describe in this paper "Rendering from Compressed High Dynamic Range Textures on

Programmable Graphics Hardware" by Peter Pike sloan and al.(ftp://ftp.research.microsoft.com/pub/tr/TR-2006-152.pdf)

 

What I don't understand is that A and B seem different. I can't understand what is store.

Are they storing for each band the triplet RGB of SH coeeficient, mean 3 float value for two DXT5 x order

or do they store store 5 SH coefficient for channel color R in two DXT5 ?

 

So what are the total storage cost of all the 5 * 3 float value in term of DXT5 texture ?

Cause It looks like to be pretty big.

 

Thanks for anyone interested by this post

 

Best regards

 

Lagarde Sébastien