Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Alen Ladavac <alenlml@cr...>  20060422 18:11:53

Thanks a bunch! This does the trick. The reference I was using for differential angle obviously got it wrong, plus I didn't do the cos kernel convolution correctly. For an additional note, r^(3/2) is not quite correct in this context. I messed that while retyping C into pcode. It should be only r^3. The full expression from that Mathworld article is (x^2+y^2+z^2)^(3/2), but since r is already length, not length squared, the square root should be dropped. So the differential angle for a point on a (1,+1)^3 cube is r^3. With this formulation, sum(diffangle * pointarea) / numpoints approaches 4*PI, so it seems to be correct. Now that my cubemap to SH code is fine, I'm getting curious about my directional light to SH formulae. They work perfectly, but I don't understand why. :) I use the coefficients mentioned before: > 0.282095*0.282095 * PI*16/17 * 1, > 0.488603*0.488603 * PI*16/17 * 2/3, > 1.092548*1.092548 * PI*16/17 * 1/4, > 0.315392*0.315392 * PI*16/17 * 1/4, > 0.546274*0.546274 * PI*16/17 * 1/4 The decimal numbers are from the SH basis (1/2*sqrt(pi) etc). They are squared to save on one more multiplication at runtime. The 1, 2/3 and 1/4 factors are from the cosine convolution. I reckon PI is because I need to transform irradiance integral into outgoing radiance. But I still don't know what's 16/17 doing there. I recall that it supposedly has something to do with 17/16*4 being the sum of 1 + 3*2/3 + 5*1/4. But why is that sum used here, and not when cosine kernel is added to the cubemap projection. And what about the 4? Any explanation or clue on this are warmly welcome. :) Thanks, Alen Saturday, April 22, 2006, 2:27:00 AM, you wrote: > I think you are mixing a couple of things up (directional lights and > projection.) It's much easier to just think of this as projection  in > that case you get: > sum =3D 0 // vector of SH coeffs for each color channel > wt =3D 0 > For each face > For each pixel > =20 > vdir =3D position on cube (domain is (1,+1)^3) > r =3D len(vdir); > vdir /=3D r; > da =3D 24.0*r^(3/2) > wt +=3D da > rgb =3D sample the pixel value > rgb *=3D da; > =20 > addtoSHC(rgb,vdir,sum) > =20 > sum *=3D 4*Pi/wt > addtoSHC should just evaluate the SH basis functions in direction dir. > wt/num_pixels should equal 4*Pi (but it won't be exactly on the CPU, so > I tend to do this normalization), so you can just not accumulate the > total weight and instead just divide sum by the # of pixels. > The addtoSHC should literally just be evaluating the basis functions (if > you want to convolve with the normalized cosine kernel just scale the > bands by 1,2/3,1/4,0,etc.) > PeterPike Sloan > (the differential solid angle term is where the r(3/2) comes from  > it's commonly used when computing form factors in radiosity, a > derivation is here: > http://mathworld.wolfram.com/SolidAngle.html=20 > for what amounts to a cube map. A factor of 4.0 is used in the > numerator of a single face, where 24 can be used for the full cube (it's > just the area of the cube so that when you divide by the number of > samples you get the correct fraction of 4*Pi  if you do the > normalization yourself this doesn't matter of course since it just > cancels out...) ) > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On Behalf Of Alen > Ladavac > Sent: Friday, April 21, 2006 9:10 AM > To: gdalgorithmslist@... > Subject: [Algorithms] Cubemap to spherical harmonics (again) > Hi list, > I believe that this issue, even though discussed a lot, was never > completely clarified in one place. So as my implementation is a kind > of a Frankenstein creation stitched from fragments of math that I > understand and pieces that still make by head steam, I guess it can't > hurt to run the actual result by some people that comprehend the SH > math better than me. > The reason I ask is that when I run it on a cube that has upper half > pure red and lower half pure green, I get something that I don't quite > expect. Upon evaluating the resulting SH in various directions, I get > mostly yellow everywhere, with just a tiny bit of red/green in the > up/down directions. > Even with the cosine term, I'd expect the straight up/down directions > to be pure red/green. Is my expectation wrong, or is the problem in my > implementation? > Here is the pcode: > correction =3D 1/(PI*16/17) > pixelarea =3D 4/(sizeU*sizeV) > for each face on the cube > for each pixel on the face > vdir =3D position on cube (domain is (1,+1)^3) > r =3D len(vdir); > vdir /=3D r; > da =3D pixelarea*r^(3/2) > rgb =3D sample the pixel value > rgb *=3D angle * correction; > addtoSHC(rgb,dir) > Where "addtoSHC()" is the one normally used by the directional light. > I.e. it uses the squared factors with extra corrections: > 0.282095*0.282095 * PI*16/17 * 1, > 0.488603*0.488603 * PI*16/17 * 2/3, > 1.092548*1.092548 * PI*16/17 * 1/4, > 0.315392*0.315392 * PI*16/17 * 1/4, > 0.546274*0.546274 * PI*16/17 * 1/4 > I also tried using the plain set of factors for adding (without the > squaring and the corrections), but I get even stranger results. > Thanks in advance for any insight, > Alen >  > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with preintegrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.asus.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >  > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with preintegrated technology to make your job ea= sier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.asus.falkag.net/sel?cmdlnk&kid=120709&bid&3057&dat=121642 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 =20 Best regards, Alen mailto:alenlml@... 