RE: [Algorithms] Light transfer in the HL2 basis

[Jon S. <jo...@do...>]

I see, so if I were to evaluate each of the SH basis functions in a =
given direction, would this be equivalent to projecting the directed =
cosine lobe onto the SH basis (rather than projecting the direction =
vector itself)?
=20
-----Original Message-----
From: Christian Sch=FCler [mailto:c.s...@ph...]=20
Sent: Tuesday, January 31, 2006 1:35 AM
To: gda...@li...
Subject: RE: [Algorithms] Light transfer in the HL2 basis
=20
Just a little point.
When you say you want to project one of the HL2 vectors onto an SH =
basis, you really want to project the directed cosine-lobe. (You cant =
really project a vector). If that's what you meant.
=20
	-----Original Message-----
	From: gda...@li... =
[mailto:gda...@li...] On Behalf Of Jon =
Stone
	Sent: Monday, January 30, 2006 8:12 PM
	To: gda...@li...
	Subject: RE: [Algorithms] Light transfer in the HL2 basis
	> This shouldn't be just shooting a ray in these 3 directions, but =
actually projecting the visibility function into this basis
	> (matrix in appendix shows to do this from SH...)
	=20
	That's a good point, and I don't mean to imply that the occlusion =
scalars should be calculated with single raycasts along the basis =
vectors.  My original plan (and please let me know if this is a correct =
one) was to project each of the HL2 vectors into spherical harmonics, =
then to take the dot product between these vectors and the SH transfer =
vector to produce the three occlusion scalars.  I'll also definitely =
check out the matrix you list in your paper, since it's designed to =
handle this specific projection (SH -> HL2).
	=20
	> One final issue is where do you fold the cosine term in - with the =
visibility function, or in the lighting environment?  I think
	> the lighting environment makes the most sense (see the split of the =
integral below...)
	=20
	Yes, absolutely.  The plan is for the 'diffuse irradiance map' to store =
the scene lighting convolved with the cosine kernel, and for the =
'specular irradiance map' to store the scene lighting convolved with the =
Phong kernel (for some specular power).  This is the model we currently =
use in our game engine, and to handle different types of materals we =
generate a number of specular irradiance maps for each environment.
	=20
	> You are approximating this integral:
	>
	> int(V(s)*Hn(s)*L(s))
	>
	> with this product:
	>
	> int(V(s))*int(Hn(s)*L(s))
	=20
	That's true, and it probably makes this method a closer analogue to =
ambient occlusion than to PRT (since AO relies on a similar =
approximation).  The main difference I see is that the V(s) term for =
ambient occlusion is a constant at each texel, while the V(s) term here =
is a function of the light direction, which should allow it to respond =
more dynamically to the view-dependent R vector for specular lighting or =
the varying L vector of a local light source.
	=20
	Jon
	=20
	-----Original Message-----
	From: Peter-Pike Sloan [mailto:pp...@wi...]=20
	Sent: Sunday, January 29, 2006 10:10 AM
	To: gda...@li...
	Subject: RE: [Algorithms] Light transfer in the HL2 basis
	=20
	I think this type of approach makes sense - you basically just want to =
encode some approximation to hemispherical visibility and then modulate =
the results with unshadowed color.  There is some language in your post =
that I think you need to be careful about:
	=20
	"At pre-process time, we would store three scalars at each texel on the =
model's surface, representing the occlusion along each of the three =
vectors of the HL2 basis"
	=20
	This shouldn't be just shooting a ray in these 3 directions, but =
actually projecting the visibility function into this basis (matrix in =
appendix shows to do this from SH...)  One final issue is where do you =
fold the cosine term in - with the visibility function, or in the =
lighting environment?  I think the lighting environment makes the most =
sense (see the split of the integral below...)
	=20
	You are approximating this integral:
	=20
	int(V(s)*Hn(s)*L(s))
	=20
	Where V(s) is spherical visibility, Hn(s) is the cosine term in the =
normal direction and L(s) is the lighting environment, integral is over =
the sphere.
	=20
	with this product:
	=20
	int(V(s))*int(Hn(s)*L(s))=20
	=20
	Which is very accurate when the visibility is extremely restricted (ie: =
mostly shadowed), but the approximation grows as the solid angle of =
visibility increases.  Of course there are other sources of =
approximation error (in particular projection into whatever basis you =
are using to encode visibility - the irradiance computation has fairly =
low error on it's own as shown in ravi's paper.)
	=20
	I think  I've talked about this kind of thing during one of my dev day =
talks at GDC (relating PRT to specular reflection and normal mapping), =
but I'd have to look through my slides to be sure.
	=20
	-Peter-Pike
	=20
	(I think there was a typo in the valve GDC slides - the basis vectors =
in the HL2 basis should be orthogonal - which they are in the figure, =
but not the equations.  In my I3D paper I use the equations there, which =
are orthogonal.)
	=20
	=20
=09
  _____ =20

	From: gda...@li... =
[mailto:gda...@li...] On Behalf Of Jon =
Stone
	Sent: Thursday, January 26, 2006 6:49 PM
	To: gda...@li...
	Subject: [Algorithms] Light transfer in the HL2 basis
	Hi all,
	=20
	We've been working on an implementation of local deformable PRT (from =
Peter-Pike Sloan's 2005 Siggraph paper), and so far we've been taking =
the approach of storing the first four ZH coefficients of light transfer =
in a texture, and convolving this with the SH light environment at =
run-time (as described in the Siggraph paper, and implemented in the =
DirectX SDK).
	=20
	One idea that occurred to us is that the Half-Life 2 basis could make a =
good alternative for storing light transfer, because the blending of a =
light environment with this simplified transfer would be very efficient =
to evaluate in a pixel shader (though less accurate visually), and could =
easily be applied to both the diffuse and specular components of =
lighting.
	=20
	Here is a rough outline of the idea, which I wanted to run by the =
excellent GDAlgorithms crew before getting too carried away with an =
implementation:
	=20
	At pre-process time, we would store three scalars at each texel on the =
model's surface, representing the occlusion along each of the three =
vectors of the HL2 basis.  To calculate lighting at run-time, we would =
first look up the unshadowed lighting in a diffuse irradiance cubemap, =
indexed by the per-pixel surface normal.  Then to calculate directional =
occlusion we would use a similar approach as in the HL2 paper - taking =
the dot product between the shading normal and the three HL2 vectors in =
tangent space, and using these three weights to blend between the three =
scalars stored in the occlusion texture.  The final diffuse color would =
then just be the product of the unshadowed light color and the =
directional occlusion.
	=20
	For specular lighting, the reflection vector would be used instead of =
the surface normal, and the cubemap would be a specular irradiance =
cubemap, but otherwise the same process would be applied.
	=20
	This approach wouldn't be able to match the visual fidelity of full =
PRT/LDPRT, because only a single direction-dependent scalar is applied =
to the light color returned from each cubemap, while the lighting result =
in PRT is a full convolution of the light environment and transfer =
functions.  But on the other hand, it could potentially look much better =
than simple ambient occlusion, which has no directional response to =
light at all, and the run-time cost wouldn't be much greater than that =
for rendering AO: only a single occlusion texture is indexed, and the =
pixel-shader math is very lightweight.
	=20
	Any thoughts on how this might work in practice, or suggestions from =
those who have implemented their own solutions to PRT?
	=20
	For reference, here are the original papers on radiosity normal mapping =
and LDPRT, and also a recent article from Peter-Pike Sloan which =
discusses another way to use the HL2 basis in PRT rendering:
	=20
	www.moonpod.com/board/images/ misc/D3DTutorial10_Half-Life2_Shading.pdf
	research.microsoft.com/~ppsloan/ldprt_final05.pdf
	research.microsoft.com/~ppsloan/NMPRT.pdf
	=20
	Thanks,
	=20
	Jon Stone
	Double Fine Productions
	=20