From: PeterPike Sloan <ppsloan@wi...>  20060422 00:27:18

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 =09 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; =09 addtoSHC(rgb,vdir,sum) =09 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=3D= 121642 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Alen Ladavac <alenlml@cr...>  20060421 16:10:13

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 = 1/(PI*16/17) pixelarea = 4/(sizeU*sizeV) for each face on the cube for each pixel on the face vdir = position on cube (domain is (1,+1)^3) r = len(vdir); vdir /= r; da = pixelarea*r^(3/2) rgb = sample the pixel value rgb *= 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 
From: <castano@gm...>  20060421 22:01:28

That seems to be right and is pretty close to what I do. The only difference is that I compute the area element in a different way, computing the solid angle of the texel polygon using Girard's formula: omega =3D sum_i(alpha_i  (n2)*pi) where alpha_i is the dihedral angle between the planes that form the polygon and n is the number of planes (Graphic Gems R27, R6). You can find another derivation of the area element of the texels of the cube map in Manne Ohrstrom thesis: http://coblitz.codeen.org:3125/citeseer.ist.psu.edu/cache/papers/cs/30957/h= ttp:zSzzSzwww.student.lu.sezSz~cif97mohzSzthesis.pdf/sphericalharmonicspr= ecomputedradiance.pdf I assume that r^3/2 is the differential solid angle, where did you get that result? With a low number of coefficients, the results usually look weird, but after convoling it with the cosine term and sampling it, you end up getting the nice results.  Ignacio Casta=F1o castano@... On 4/21/06, Alen Ladavac <alenlml@...> wrote: > 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 
From: PeterPike Sloan <ppsloan@wi...>  20060422 00:27:18

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 =09 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; =09 addtoSHC(rgb,vdir,sum) =09 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=3D= 121642 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
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@... 
From: PeterPike Sloan <ppsloan@wi...>  20060423 15:57:40

The Pi*16/17 factors comes from the notion of a normalized ([0,1] space) directional light. It is derived by solving for a scale factor that given a normal pointed in Z with a directional light shining right on it and unit albedo would reflect 1.0. But I don't think you need this  you just need to integrate the RGB values against the raw SH basis functions (there should be 9 through the cubics  not sure why you are just showing 5 below and they are polynomials of the normalized direction.) PeterPike Sloan Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Alen Ladavac Sent: Saturday, April 22, 2006 11:12 AM To: PeterPike Sloan Cc: gdalgorithmslist@... Subject: Re[2]: [Algorithms] Cubemap to spherical harmonics (again) 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=3D= 121642 > _______________________________________________ > 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 easier > 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@...  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=3Dk&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 
From: Alen Ladavac <alenlml@cr...>  20060423 19:29:27

Oh I see. Makes sense, of course. I thought it was something more complicated. I'm not using this for cube>sh (not anymore at least), I'm using those factors for directional light. But now that I understand some stuff here better, I started getting curious about how exactly does the directional light to sh conversion works. But it's all snapping into place now. Thanks for all your help. I only list 5 numbers as the 9 polymonials repeat the same 5 coefficients, so no need to repeat them. The polynomials are in fact: c0 c1*y c1*z c1*x c2*x*y c2*y*z c3*(2z*z1) c2*x*z c4*(x*xy*y) Do you see a problem there, or is it all ok? Thanks, Alen Sunday, April 23, 2006, 5:57:33 PM, you wrote: > The Pi*16/17 factors comes from the notion of a normalized ([0,1] space) > directional light. It is derived by solving for a scale factor that > given a normal pointed in Z with a directional light shining right on it > and unit albedo would reflect 1.0. But I don't think you need this  > you just need to integrate the RGB values against the raw SH basis > functions (there should be 9 through the cubics  not sure why you are > just showing 5 below and they are polynomials of the normalized > direction.) > PeterPike Sloan > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On Behalf Of Alen > Ladavac > Sent: Saturday, April 22, 2006 11:12 AM > To: PeterPike Sloan > Cc: gdalgorithmslist@... > Subject: Re[2]: [Algorithms] Cubemap to spherical harmonics (again) > 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 > easier >> 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@... 
From: Tom Forsyth <tom.gdalgo@ee...>  20060424 00:08:29

> c3*(2z*z1) I think this should be c3*(3*z*z1). A three, not a two. TomF. > Original Message > From: gdalgorithmslistadmin@...=20 > [mailto:gdalgorithmslistadmin@...] On=20 > Behalf Of Alen Ladavac > Sent: 23 April 2006 12:25 > To: gdalgorithmslist@... > Subject: Re[4]: [Algorithms] Cubemap to spherical harmonics (again) >=20 >=20 > Oh I see. Makes sense, of course. I thought it was something more > complicated. >=20 > I'm not using this for cube>sh (not anymore at least), I'm using > those factors for directional light. But now that I understand some > stuff here better, I started getting curious about how exactly does > the directional light to sh conversion works. But it's all snapping > into place now. Thanks for all your help. >=20 > I only list 5 numbers as the 9 polymonials repeat the same 5 > coefficients, so no need to repeat them. The polynomials are in fact: >=20 > c0 > c1*y > c1*z > c1*x > c2*x*y > c2*y*z > c3*(2z*z1) > c2*x*z > c4*(x*xy*y) >=20 > Do you see a problem there, or is it all ok? >=20 > Thanks, > Alen >=20 >=20 >=20 > Sunday, April 23, 2006, 5:57:33 PM, you wrote: >=20 > > The Pi*16/17 factors comes from the notion of a normalized=20 > ([0,1] space) > > directional light. It is derived by solving for a scale factor that > > given a normal pointed in Z with a directional light=20 > shining right on it > > and unit albedo would reflect 1.0. But I don't think you=20 > need this  > > you just need to integrate the RGB values against the raw SH basis > > functions (there should be 9 through the cubics  not sure=20 > why you are > > just showing 5 below and they are polynomials of the normalized > > direction.) >=20 > > PeterPike Sloan >=20 > > Original Message > > From: gdalgorithmslistadmin@... > > [mailto:gdalgorithmslistadmin@...] On=20 > Behalf Of Alen > > Ladavac > > Sent: Saturday, April 22, 2006 11:12 AM > > To: PeterPike Sloan > > Cc: gdalgorithmslist@... > > Subject: Re[2]: [Algorithms] Cubemap to spherical harmonics (again) >=20 > > 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. >=20 > > For an additional note, r^(3/2) is not quite correct in=20 > this context. > > I messed that while retyping C into pcode. It should be=20 > 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. >=20 > > 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. :) >=20 > > I use the coefficients mentioned before: >=20 > >> 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 >=20 > > The decimal numbers are from the SH basis (1/2*sqrt(pi)=20 > etc). They are > > squared to save on one more multiplication at runtime. The=20 > 1, 2/3 and > > 1/4 factors are from the cosine convolution. I reckon PI is=20 > 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=20 > 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=20 > is added to > > the cubemap projection. And what about the 4? Any=20 > explanation or clue > > on this are warmly welcome. :) >=20 > > Thanks, > > Alen >=20 >=20 > > Saturday, April 22, 2006, 2:27:00 AM, you wrote: >=20 > >> I think you are mixing a couple of things up (directional=20 > lights and > >> projection.) It's much easier to just think of this as=20 > projection  > > in > >> that case you get: >=20 > >> sum =3D 0 // vector of SH coeffs for each color channel > >> wt =3D 0 >=20 > >> For each face > >> For each pixel > >> =20 > >> vdir =3D position on cube (domain is (1,+1)^3) > >> r =3D len(vdir); > >> vdir /=3D r; >=20 > >> 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 >=20 > >> sum *=3D 4*Pi/wt >=20 > >> addtoSHC should just evaluate the SH basis functions in=20 > direction dir. >=20 > >> wt/num_pixels should equal 4*Pi (but it won't be exactly=20 > on the CPU, > > so > >> I tend to do this normalization), so you can just not=20 > accumulate the > >> total weight and instead just divide sum by the # of pixels. >=20 > >> The addtoSHC should literally just be evaluating the basis=20 > functions > > (if > >> you want to convolve with the normalized cosine kernel=20 > just scale the > >> bands by 1,2/3,1/4,0,etc.) >=20 > >> PeterPike Sloan >=20 > >> (the differential solid angle term is where the r(3/2)=20 > comes from  > >> it's commonly used when computing form factors in radiosity, a > >> derivation is here: >=20 > >> http://mathworld.wolfram.com/SolidAngle.html=20 >=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...) ) >=20 > >> 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) >=20 > >> Hi list, >=20 > >> I believe that this issue, even though discussed a lot, was never > >> completely clarified in one place. So as my implementation=20 > is a kind > >> of a Frankenstein creation stitched from fragments of math that I > >> understand and pieces that still make by head steam, I=20 > guess it can't > >> hurt to run the actual result by some people that comprehend the SH > >> math better than me. >=20 > >> The reason I ask is that when I run it on a cube that has=20 > upper half > >> pure red and lower half pure green, I get something that I=20 > don't quite > >> expect. Upon evaluating the resulting SH in various=20 > directions, I get > >> mostly yellow everywhere, with just a tiny bit of red/green in the > >> up/down directions. >=20 > >> Even with the cosine term, I'd expect the straight up/down=20 > directions > >> to be pure red/green. Is my expectation wrong, or is the=20 > problem in my > >> implementation? >=20 > >> Here is the pcode: >=20 > >> correction =3D 1/(PI*16/17) > >> pixelarea =3D 4/(sizeU*sizeV) >=20 > >> for each face on the cube > >> for each pixel on the face >=20 > >> vdir =3D position on cube (domain is (1,+1)^3) > >> r =3D len(vdir); > >> vdir /=3D r; >=20 > >> da =3D pixelarea*r^(3/2) >=20 > >> rgb =3D sample the pixel value > >> rgb *=3D angle * correction; > >> addtoSHC(rgb,dir) >=20 > >> Where "addtoSHC()" is the one normally used by the=20 > directional light. > >> I.e. it uses the squared factors with extra corrections: >=20 > >> 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 >=20 > >> I also tried using the plain set of factors for adding (without the > >> squaring and the corrections), but I get even stranger results. >=20 > >> Thanks in advance for any insight, >=20 > >> Alen >=20 >=20 >=20 >=20 > >>  > >> Using Tomcat but need to do more? Need to support web services, > >> security? > >> Get stuff done quickly with preintegrated technology to=20 > make your job > >> easier > >> Download IBM WebSphere Application Server v.1.0.1 based on Apache > >> Geronimo > >> > >=20 > 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 >=20 >=20 > >>  > >> Using Tomcat but need to do more? Need to support web services, > > security? > >> Get stuff done quickly with preintegrated technology to=20 > make your job > > easier > >> 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 >=20 >=20 >=20 >=20 >=20 > =20 > Best regards, > Alen mailto:alenlml@... >=20 >=20 >=20 >  > Using Tomcat but need to do more? Need to support web=20 > services, security? > Get stuff done quickly with preintegrated technology to make=20 > your job easier > Download IBM WebSphere Application Server v.1.0.1 based on=20 > Apache Geronimo > http://sel.asus.falkag.net/sel?cmd=3Dk&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 
From: Alen Ladavac <alenlml@cr...>  20060424 06:02:23

Monday, April 24, 2006, 2:08:20 AM, Tom wrote: >> c3*(2z*z1) > I think this should be c3*(3*z*z1). A three, not a two. Yes. Right. Another typo. Looks like I should be more careful when retyping from C into pseudocode. Alen 
From: Ben Garney <beng@ga...>  20060422 07:00:19

On 4/21/06, Alen Ladavac <alenlml@...> wrote: > 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) (Disclaimer: I am a SH newbie.) Are you sure that you're getting a properly "normalized" SH? It sounds like you might be adding too much, thus getting a huge spike of red+green=3Dyellow on one basis, which overwhelms your color range... Depending on implementation details, seems like you could test this by sampling the SH in a few directions and seeing what color values you get. Also seems likely you'll get a yellow band no matter what you do, but it can probably be minimized.  Ben Garney Torque Technologies Director GarageGames.Com, Inc. 