You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(390) 
_{Aug}
(767) 
_{Sep}
(940) 
_{Oct}
(964) 
_{Nov}
(819) 
_{Dec}
(762) 

2001 
_{Jan}
(680) 
_{Feb}
(1075) 
_{Mar}
(954) 
_{Apr}
(595) 
_{May}
(725) 
_{Jun}
(868) 
_{Jul}
(678) 
_{Aug}
(785) 
_{Sep}
(410) 
_{Oct}
(395) 
_{Nov}
(374) 
_{Dec}
(419) 
2002 
_{Jan}
(699) 
_{Feb}
(501) 
_{Mar}
(311) 
_{Apr}
(334) 
_{May}
(501) 
_{Jun}
(507) 
_{Jul}
(441) 
_{Aug}
(395) 
_{Sep}
(540) 
_{Oct}
(416) 
_{Nov}
(369) 
_{Dec}
(373) 
2003 
_{Jan}
(514) 
_{Feb}
(488) 
_{Mar}
(396) 
_{Apr}
(624) 
_{May}
(590) 
_{Jun}
(562) 
_{Jul}
(546) 
_{Aug}
(463) 
_{Sep}
(389) 
_{Oct}
(399) 
_{Nov}
(333) 
_{Dec}
(449) 
2004 
_{Jan}
(317) 
_{Feb}
(395) 
_{Mar}
(136) 
_{Apr}
(338) 
_{May}
(488) 
_{Jun}
(306) 
_{Jul}
(266) 
_{Aug}
(424) 
_{Sep}
(502) 
_{Oct}
(170) 
_{Nov}
(170) 
_{Dec}
(134) 
2005 
_{Jan}
(249) 
_{Feb}
(109) 
_{Mar}
(119) 
_{Apr}
(282) 
_{May}
(82) 
_{Jun}
(113) 
_{Jul}
(56) 
_{Aug}
(160) 
_{Sep}
(89) 
_{Oct}
(98) 
_{Nov}
(237) 
_{Dec}
(297) 
2006 
_{Jan}
(151) 
_{Feb}
(250) 
_{Mar}
(222) 
_{Apr}
(147) 
_{May}
(266) 
_{Jun}
(313) 
_{Jul}
(367) 
_{Aug}
(135) 
_{Sep}
(108) 
_{Oct}
(110) 
_{Nov}
(220) 
_{Dec}
(47) 
2007 
_{Jan}
(133) 
_{Feb}
(144) 
_{Mar}
(247) 
_{Apr}
(191) 
_{May}
(191) 
_{Jun}
(171) 
_{Jul}
(160) 
_{Aug}
(51) 
_{Sep}
(125) 
_{Oct}
(115) 
_{Nov}
(78) 
_{Dec}
(67) 
2008 
_{Jan}
(165) 
_{Feb}
(37) 
_{Mar}
(130) 
_{Apr}
(111) 
_{May}
(91) 
_{Jun}
(142) 
_{Jul}
(54) 
_{Aug}
(104) 
_{Sep}
(89) 
_{Oct}
(87) 
_{Nov}
(44) 
_{Dec}
(54) 
2009 
_{Jan}
(283) 
_{Feb}
(113) 
_{Mar}
(154) 
_{Apr}
(395) 
_{May}
(62) 
_{Jun}
(48) 
_{Jul}
(52) 
_{Aug}
(54) 
_{Sep}
(131) 
_{Oct}
(29) 
_{Nov}
(32) 
_{Dec}
(37) 
2010 
_{Jan}
(34) 
_{Feb}
(36) 
_{Mar}
(40) 
_{Apr}
(23) 
_{May}
(38) 
_{Jun}
(34) 
_{Jul}
(36) 
_{Aug}
(27) 
_{Sep}
(9) 
_{Oct}
(18) 
_{Nov}
(25) 
_{Dec}

2011 
_{Jan}
(1) 
_{Feb}
(14) 
_{Mar}
(1) 
_{Apr}
(5) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}
(37) 
_{Sep}
(6) 
_{Oct}
(2) 
_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(10) 
2013 
_{Jan}

_{Feb}
(1) 
_{Mar}
(7) 
_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2014 
_{Jan}
(14) 
_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

_{Dec}
(1) 
2016 
_{Jan}

_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(1) 
_{May}

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(4) 
2
(3) 
3
(3) 
4
(4) 
5
(10) 
6
(10) 
7
(6) 
8
(8) 
9
(1) 
10
(7) 
11
(7) 
12
(6) 
13
(6) 
14
(19) 
15
(1) 
16

17
(2) 
18
(3) 
19
(1) 
20

21
(2) 
22
(3) 
23
(2) 
24
(2) 
25

26
(3) 
27
(26) 
28
(4) 
29
(4) 
30







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: 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. 
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 