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}

S  M  T  W  T  F  S 





1
(7) 
2

3

4
(10) 
5
(12) 
6
(15) 
7
(2) 
8
(8) 
9
(7) 
10
(1) 
11
(6) 
12
(7) 
13
(13) 
14
(35) 
15
(17) 
16
(15) 
17
(12) 
18
(4) 
19
(13) 
20

21

22

23
(15) 
24
(6) 
25
(4) 
26
(19) 
27
(33) 
28
(16) 
29
(31) 
30
(30) 

From: Per Vognsen <Per.V<ognsen@ep...>  20040415 21:43:15

> Original Message > From: gdalgorithmslistadmin@...=20 > [mailto:gdalgorithmslistadmin@...] On=20 > Behalf Of Andy Sloane > Sent: Thursday, April 15, 2004 4:48 PM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] CapsuleOBB separating axes >=20 > > Not quite. Unfortunately this doesn't even work for testing=20 > a sphere=20 > > (the degenerate case of a capsule) against a box. Consider the=20 > > twodimensional case, for the sake of simplicity. >=20 > Duh! Thank you, I was being naive. I think most people make this mistake initially (myself included). Don't sweat it! > > Exercise: Generalize the above enumeration of separating=20 > axes for the=20 > > boxsphere case to the more general boxcapsule case. :) >=20 > Hmm.. So the separating axes for the degenerate case (sphere)=20 > would be: > 3  three box axes > 8  (each vertex of box)  (sphere center) > 12  perpendicular to each edge toward sphere center Right. A somewhat orthogonal observation: When writing productionquality code for this separating axis method, it makes sense to first check the vertex axes, then the edge axes and finally the face edges for earlyout purposes. If you visualize the regions corresponding to the different kinds of features, that should make a lot of sense: The closestfeature region corresponding to a vertex is conelike and keeps growing in all three directions as you move away. The region for an edge is wedgeshaped and only grows in two dimensions while the slablike region for a face only grows in one dimension. Thus, when at a reasonable distance to the box (compared to its size), you are more likely to fall in a vertex region than, say, a face region. > except you'd only really need to consider the nearest vertex=20 > or the nearest edge, depending on the location of the sphere. Hmm. >=20 > Ugh! Ok, so in general we have: > 3  the three box axes > 3  (three box axes) x (line segment axis) > 16  (each vertex of the line segment)  (each vertex of box) > 24  perpendicular to each edge toward each vertex of the=20 > line segment >=20 > That's awful! "Pure" separating axis is probably not what I=20 > want here, eh? >=20 > So, what about this: >=20 > We use a quick boxsphere intersection test, by transforming=20 > the endpoints of the linesegment defining the capsule into=20 > box space and using, for instance, "A Simple Method for=20 > BoxSphere Intersection Testing" by Jim Avro (Graphics Gems). =20 For what it's worth, I like to think of Arvo's algorithm as an optimized separating axis method. The difference between it and a more generic method is that he only checks separating axes corresponding to vertices and faces when necessary (i.e. when the sphere center falls into the appropriate regions) and he also uses this "region classification" to add up face distances in order to get edge and vertex distances. Pretty clever, reusing the distances like that! > Then, once we've determined that the spheres defining the=20 > ends of the capsule are not intersecting, the only remaining=20 > feature is the 'extrusion' > of the line segment, and then we only need to check the 6=20 > line segment axes... or am I missing something yet again? No, sounds good to me but of course I've been known to make mistakes. Anyway, I hope it at least comforts you to know that Arvo's algorithm is really the separating axis method in disguise :) Per 
From: PeterPike Sloan <ppsloan@wi...>  20040415 21:40:34

Garys solution is simple as well (do 3 simulations with the basis vectors as normals  of course you just keep 3 times as much data around I think...), I'd have to think about how this interplays with his squared basis functions though. It might not be mathematically correct  I think the most accurate way to do this using these 3 basis functions would be to: A) Compute radiosity solution using the "normal" normal. B) Compute integrals of incident radiance against each of the quadratic basis functions at every texel in the light map (3 numbers per color channel.) C) Compute linear operator that does least squares projection of above signal (maybe limit domain of integration to where all 3 basis functions are visible?) into this basis, projects that signal into spherical harmonics, convolves it with the normalized cosine kernel, does a least squares projection back into this quadratic basis. This will just be a 3x3 matrix that you compute offline...=20 The above assumes that using the "default" normal is ok when simulating the flow of light in the scene (not sure what gary does  Andrew Willmott is more of a radiosity expert than I am, maybe he knows of similar techniques?) I believe that's not too egregious of an assumption... PeterPike (When looking at least squares projections you can limit (or weight) the domain of integration so that you try and approximate the area where you think most normals will occur  inbetween the 3 basis vectors. This is just another example of the least squares stuff in my previous post, with the caveat that you might want to have a positive weight function outside of the squared error term...) Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Newport, Matthew Sent: Thursday, April 15, 2004 1:55 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" So do you just do this as an extra pass at the end as PeterPike Sloan suggested? Assuming you are treating all the surfaces as perfectly diffuse it seems you don't actually have to modify the radiosity processor as I was originally thinking, is that right? Matt. Original Message From: Gary McTaggart [mailto:gary@...] Sent: Thursday, April 15, 2004 1:31 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" Instead of getting light values at the normal per lightmap texel, move the basis from the slides into tangent space and light those three vectors instead.=20 Gary Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Newport, Matthew Sent: Thursday, April 15, 2004 12:26 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" This is the bit that's been puzzling me as well  can anyone explain how the offline radiosity simulator was modified from standard radiosity to generate the three directional components (three lightmaps)?=20 Matt Newport Original Message From: PeterPike Sloan [mailto:ppsloan@...] Sent: Wednesday, April 14, 2004 2:32 AM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" <SNIP> ((*)I think the first part is mathematically equivalent to using just the linear SH term (no constant) to compute exit radiance from some precomputed data (3 colors) and the surface normal. How the offline simulation was modified to generate these 3 colors is the interesting bit  I would imagine you could compute the linear SH representation of incident radiance at every point and get very similar results...)  This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88  This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88  This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: PeterPike Sloan <ppsloan@wi...>  20040415 21:08:48

After playing around with these a bit more here are some observations: 1) Through the quadratics there are only 6 SH basis functions that integrate to nonzero against this basis (constant + linear + 2 quadratics) (there are also 5 of the 7 cubics  but it turns out this doesn't matter  more later.) That means 3 of them are in the nullspace of garys basis (the cross terms ones xy,xz and yz.) 2) Lets assume we want to represent (using garys basis) for any normal direction the lighting environment convolved with a cosine kernel in that direction (this is a spherical function), we can set up a series of analytic transformations that do this: Coeffs =3D (MlsMs>gCMg>sMls)*f f are the "raw" projection coefficients in garys basis The M's are a bunch of linear operators (matrices), in particular: Mls  matrix that maps from "raw" projection coefficients to "least squares" projection coefficients (defined later) Mg>s  matrix that maps from "garys" basis to "spherical harmonics" Basis (just integrate garys basis against SH basis) C  diagonal matrix that represents convolution with normalized cosine function (so that when evaluating a normal you get the integral of the lighting environment against the cosine function in that direction.) This is the result of ravi's 2001 siggraph paper (but ravi didn't do a divide by Pi that should be done to convert this into exit radiance, he used the unormalized integral.) Ms>g  matrix that maps from a function represented in quadratic spherical harmonics to "garys" basis (transpose of Mg>s) All of these matrices can be computed analytically, and the composite matrix has a very simple structure: Aii =3D 43/(32Pi) Aij =3D 7/(32Pi) (j is "opposite" of i) Aij =3D 3/(32Pi) (j is any other basis function) So given the above matrix and the "raw" projection of the lighting environment into garys basis you get a spherical function that approximates what the exit radiance would be for any normal direction (the result of integrating the incident radiance function against the clamped cosine kernel in the give normal direction.) It turns out that this is 100% as accurate as garys basis can represent this signal (if you prefiltered the spherical lighting environment and projected it you would get the identical results.) This is because the analytic integration of garys basis functions against the SH basis equals zero for even order >=3D 4, while the analytic integral of the cosine kernel integrates to zero for odd orders >=3D 3 so the only terms that can affect this are the basis functions through the quadratics that don't integrate to zero. Here is how well garys basis can approximate the quadratic SH, this is squared error integrated over the sphere (worst case error would be larger...) Here are the actual squared errors integrated over the sphere: Y00,Y20,Y22 > 0 Y11,Y10,Y11 > 0.0625 Y22,Y21,Y21 > 1 (ie: it approximates it as zero...) The least squares projections of the linear basis functions are interesting: Y10 =3D z*sqrt(3/Pi)*(1/2) Approximation is 5/8*sqrt(3/Pi)*Zp  5/8*sqrt(3/Pi)*Zm Where Zp is z^2 when z > 0, 0 other wise and Zm is its opposite basis function. It increased the value at z=3D+1 (from 1/2 to 5/8) to make = the squared error less. Clearly you can only do so good a job approximating a linear function with a quadratic one though... Garys basis is nice because of the low evaluation overhead, and I think it would work fine for static lighting.=20 PeterPike (Given a set of basis functions defined over some domain (we're using the sphere but this works for any domain) and a function you want to approximate with the given basis, how do you chose coefficients that approximate the function as accurately as possible? One way is to find the coefficients that minimize squared error integrated over the domain: Err =3D Int( (sum(ci*Bi)  f)^2 ) ci are the coefficients we are trying to find Bi are the basis functions (functions  not constants) f is the function we are trying to approximate Err is the squared error. Differentiate this with respect to ck and you get: dErr/dck =3D 2*int( (sum(ci*Bi)  f)*Bk ) =3D 2*int( sum(ci*Bi*Bk) )  2*int(f*Bk) The second partials are the basis functions integrated against themselves (which is always positive) so if we solve for the first derivative equal to zero we have a minima. You have N linear equations: Int( sum(ci*Bi*Bk) ) =3D int(f*Bk) =3D> sum(ci*int(Bi*Bk)) =3D int(f*Bk) And N unknowns (the ci), build a matrix: Aij =3D int(Bi*Bj) The right hand side is: bi =3D int(f*Bi) And solve for x (the c's in this case  just invert matrix A and multiply it by the vector b...) If the basis function are orthonormal A is just the identity matrix. So given garys basis, what happens if we don't do this? What if we just integrate the signal against the "raw" basis functions and use those as coefficients? Lets assume the signal is just one of the raw basis functions (say x^2 where x is in [0,1]) we know that it must be able to represent that. The raw integrals are 2*Pi/5 for the basis function against itself (diagonals in the A matrix above), the "opposite" basis function integrates to zero and the other four to Pi/15. So raw projection will give you a brighter (should be 1 at x=3D1, but is 2Pi/5), blurrier (energy in 4 other basis functions) signal. If you do the least squares projection (matrix has the following structure: Aii =3D 11/(4*Pi) Aij =3D 1/(4*Pi) when j is the "opposite" basis function Aij =3D 3/(8*Pi) when j is any other basis function You end up with the correct result (1 for the basis function in question, zero for all of the others...) This will also allow you to integrate correctly against constant functions (otherwise the constant function will be too bright  it would have a value of 2Pi/3*C instead of C where C is the constant value you are trying to represent.) So now what signal do you want to project into this basis? You want to use the normal to evaluate a spherical function that gives you the reflected light in that direction from the incident radiance environment, so we're back at my observation 2 above...) 
From: Newport, Matthew <mnewport@ea...>  20040415 20:55:41

So do you just do this as an extra pass at the end as PeterPike Sloan suggested? Assuming you are treating all the surfaces as perfectly diffuse it seems you don't actually have to modify the radiosity processor as I was originally thinking, is that right? Matt. Original Message From: Gary McTaggart [mailto:gary@...]=20 Sent: Thursday, April 15, 2004 1:31 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" Instead of getting light values at the normal per lightmap texel, move the basis from the slides into tangent space and light those three vectors instead.=20 Gary Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Newport, Matthew Sent: Thursday, April 15, 2004 12:26 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" This is the bit that's been puzzling me as well  can anyone explain how the offline radiosity simulator was modified from standard radiosity to generate the three directional components (three lightmaps)?=20 Matt Newport Original Message From: PeterPike Sloan [mailto:ppsloan@...] Sent: Wednesday, April 14, 2004 2:32 AM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" <SNIP> ((*)I think the first part is mathematically equivalent to using just the linear SH term (no constant) to compute exit radiance from some precomputed data (3 colors) and the surface normal. How the offline simulation was modified to generate these 3 colors is the interesting bit  I would imagine you could compute the linear SH representation of incident radiance at every point and get very similar results...)  This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88  This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: Andy Sloane <andy@gu...>  20040415 20:47:55

> Not quite. Unfortunately this doesn't even work for testing a sphere > (the degenerate case of a capsule) against a box. Consider the > twodimensional case, for the sake of simplicity. Duh! Thank you, I was being naive. > Exercise: Generalize the above enumeration of separating axes for the > boxsphere case to the more general boxcapsule case. :) Hmm.. So the separating axes for the degenerate case (sphere) would be: 3  three box axes 8  (each vertex of box)  (sphere center) 12  perpendicular to each edge toward sphere center except you'd only really need to consider the nearest vertex or the nearest edge, depending on the location of the sphere. Hmm. Ugh! Ok, so in general we have: 3  the three box axes 3  (three box axes) x (line segment axis) 16  (each vertex of the line segment)  (each vertex of box) 24  perpendicular to each edge toward each vertex of the line segment That's awful! "Pure" separating axis is probably not what I want here, eh? So, what about this: We use a quick boxsphere intersection test, by transforming the endpoints of the linesegment defining the capsule into box space and using, for instance, "A Simple Method for BoxSphere Intersection Testing" by Jim Avro (Graphics Gems). Then, once we've determined that the spheres defining the ends of the capsule are not intersecting, the only remaining feature is the 'extrusion' of the line segment, and then we only need to check the 6 line segment axes... or am I missing something yet again? Andy 
From: Gary McTaggart <gary@va...>  20040415 20:30:57

Instead of getting light values at the normal per lightmap texel, move the basis from the slides into tangent space and light those three vectors instead.=20 Gary Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Newport, Matthew Sent: Thursday, April 15, 2004 12:26 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" This is the bit that's been puzzling me as well  can anyone explain how the offline radiosity simulator was modified from standard radiosity to generate the three directional components (three lightmaps)?=20 Matt Newport Original Message From: PeterPike Sloan [mailto:ppsloan@...] Sent: Wednesday, April 14, 2004 2:32 AM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" <SNIP> ((*)I think the first part is mathematically equivalent to using just the linear SH term (no constant) to compute exit radiance from some precomputed data (3 colors) and the surface normal. How the offline simulation was modified to generate these 3 colors is the interesting bit  I would imagine you could compute the linear SH representation of incident radiance at every point and get very similar results...)  This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: PeterPike Sloan <ppsloan@wi...>  20040415 20:27:31

Thinking about this a bit more  you don't have to modify the offline radiosity simulator at all. All you need to do is have an extra pass. For each texel in your lightmap you have to project the converged GI solution into whatever basis you are going to use to represent exit radiance (well, you probably want to have a hemispherical function that is convolved with the cosine term  since you will be indexing it by the sufrace normal.) With SH this would ammount to just doing a projection where half the cube map is black followed by convolution. The linear SH basis functions should have similar results. I've done a lot more analasys regarding these basis functions and I'll post the results shortly... PeterPike=20 Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Newport, Matthew Sent: Thursday, April 15, 2004 12:26 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" This is the bit that's been puzzling me as well  can anyone explain how the offline radiosity simulator was modified from standard radiosity to generate the three directional components (three lightmaps)?=20 Matt Newport Original Message From: PeterPike Sloan [mailto:ppsloan@...] Sent: Wednesday, April 14, 2004 2:32 AM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" <SNIP> ((*)I think the first part is mathematically equivalent to using just the linear SH term (no constant) to compute exit radiance from some precomputed data (3 colors) and the surface normal. How the offline simulation was modified to generate these 3 colors is the interesting bit  I would imagine you could compute the linear SH representation of incident radiance at every point and get very similar results...)  This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: Newport, Matthew <mnewport@ea...>  20040415 19:26:46

This is the bit that's been puzzling me as well  can anyone explain how the offline radiosity simulator was modified from standard radiosity to generate the three directional components (three lightmaps)?=20 Matt Newport Original Message From: PeterPike Sloan [mailto:ppsloan@...]=20 Sent: Wednesday, April 14, 2004 2:32 AM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" <SNIP> ((*)I think the first part is mathematically equivalent to using just the linear SH term (no constant) to compute exit radiance from some precomputed data (3 colors) and the surface normal. How the offline simulation was modified to generate these 3 colors is the interesting bit  I would imagine you could compute the linear SH representation of incident radiance at every point and get very similar results...) 
From: Per Vognsen <Per.V<ognsen@ep...>  20040415 19:12:44

> Original Message > From: gdalgorithmslistadmin@...=20 > [mailto:gdalgorithmslistadmin@...] On=20 > Behalf Of Andy Sloane > Sent: Thursday, April 15, 2004 2:35 PM > To: gdalgorithmslist@... > Subject: Re: [Algorithms] CapsuleOBB separating axes >=20 > Thanks for the reply. >=20 > On Thu, Apr 15, 2004 at 01:52:35PM 0400, Per Vognsen wrote: > > The problem reduces to testing the line segment AB against the=20 > > convolution of the oriented box with a sphere of radius R. This=20 > > convolution can be represented as the union of these geometric > > primitives: > >=20 > > The original oriented box. > > Capsules for each edge of the original box, with radius R. > > Oriented boxes for each face, with height R. >=20 > Well, sure, but, stepping back a bit, what are the necessary=20 > separating axes for the line segment and the original box? You listed them already in your original post. They are the face normals as well as cross products of the line vector with each of the edge vectors. > My intuition is that these are the same as what are needed=20 > for the capsule and the box, because the capsule is simply an=20 > extrusion of the line segment. Or equivalently, as you=20 > suggest, an extrusion of the box could be tested against the=20 > line segment. ("extrusion" not technically being the right=20 > term here, but you know what I mean) Not quite. Unfortunately this doesn't even work for testing a sphere (the degenerate case of a capsule) against a box. Consider the twodimensional case, for the sake of simplicity.=20  1  2  _____ _ _ _ _     =20 _____ 3 This is (supposed to look like) a rectangle and the three labelled regions defined by its top and right side. Imagine a circle centered somewhere in region 2 such that it reaches into both regions 1 and 3 yet doesn't intersect the box. The separating axis test (using the two axes from regions 1 and 3, respectively) will fail in this case. We also need to check the separating axis joining the upperright vertex to the center of the sphere. This is necessary if and only if the center falls in region 2 and we can quickly decide whether this is the case by transforming to a basis in which the box is axisaligned. The threedimensional case is only slightly more complicated. There you will also need to use a special kind of separating axis when the closest feature of the sphere center is an edge. In this case the separating axis is the perpendicular dropped from the sphere center down onto the edge. Again, you can decide when this kind of axis is to be considered by working in the axisaligned frame of the box and comparing the point to the defining box intervals. So I guess the short answer would be: No, this boxcapsule problem is not at all equivalent to testing a line segment against an oriented box. Exercise: Generalize the above enumeration of separating axes for the boxsphere case to the more general boxcapsule case. :) Per 
From: Andy Sloane <andy@gu...>  20040415 18:43:45

Of course, now that I've correctly defined the actual problem I want to solve, I can just look on the internet and find this: http://www.gamasutra.com/features/19991018/Gomez_6.htm Doh! So the three box axes, and the cross product of the line segment and the three box axes, as I thought, and I don't need the line segment direction itself. Andy 
From: Andy Sloane <andy@gu...>  20040415 18:35:05

Thanks for the reply. On Thu, Apr 15, 2004 at 01:52:35PM 0400, Per Vognsen wrote: > The problem reduces to testing the line segment AB against the > convolution of the oriented box with a sphere of radius R. This > convolution can be represented as the union of these geometric > primitives: > > The original oriented box. > Capsules for each edge of the original box, with radius R. > Oriented boxes for each face, with height R. Well, sure, but, stepping back a bit, what are the necessary separating axes for the line segment and the original box? My intuition is that these are the same as what are needed for the capsule and the box, because the capsule is simply an extrusion of the line segment. Or equivalently, as you suggest, an extrusion of the box could be tested against the line segment. ("extrusion" not technically being the right term here, but you know what I mean) Andy 
From: Per Vognsen <Per.V<ognsen@ep...>  20040415 17:52:38

Hey Andy, I haven't studied Dave's code but here's an idea, which may or may not be identical to what he is doing. Let the capsule be defined by a line segment AB and a radius R. The problem reduces to testing the line segment AB against the convolution of the oriented box with a sphere of radius R. This convolution can be represented as the union of these geometric primitives: The original oriented box. Capsules for each edge of the original box, with radius R. Oriented boxes for each face, with height R. Make a few diagrams to see why this works. Anyway, given this decomposition, testing the line segment against the convolution is the same as testing the line segment against each of the components. Each of these individual tests can be done using the separating axis method. You should be able to work out the resulting separating axes, expressed directly in terms of the data defining the original oriented box. This way you don't actually construct the components explicitly and you should end up with a "pure" separating axis method. Hope this helps, Per=20 > Original Message > From: gdalgorithmslistadmin@...=20 > [mailto:gdalgorithmslistadmin@...] On=20 > Behalf Of Andy Sloane > Sent: Thursday, April 15, 2004 1:21 PM > To: gdalgorithmslist@... > Subject: [Algorithms] CapsuleOBB separating axes >=20 > Hello, >=20 > For various reasons, I would like a quick capsuleoriented box test. > Intuitively, this is equivalent to a line segmentoriented=20 > box separating axis test, except the line segment is=20 > 'inflated' by the radius when it is projected onto any axis. >=20 > The obvious choices are the axes of the box itself, the axis=20 > of the line segment, and the cross product of the latter with=20 > the former three, so seven in all. Is that it? Is that too many? =20 >=20 > More generally, one thing I'm having trouble with is that I'm=20 > not really sure how to select an axis to represent a=20 > nearcollision between the vertex of the line segment and a=20 > vertex of the box. >=20 > The segmentbox test on magicsoftware > (http://www.magicsoftware.com/Source/Intersection/WmlIntrLin3 > Box3.cpp) > utterly confounds me after the first three axes are tested. =20 > The cross product of the difference between centers and the=20 > axis of the line segment is taken, but I don't understand=20 > what's going on with the three tests after that; I can't wrap=20 > my head around the geometry. >=20 > Andy >=20 >=20 >=20 >  > This SF.Net email is sponsored by: IBM Linux Tutorials Free=20 > Linux tutorial presented by Daniel Robbins, President and CEO=20 > of GenToo technologies. Learn everything from fundamentals to=20 > system=20 > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 >=20 
From: Nouri, Salah <snouri@pa...>  20040415 17:30:28

Hi, do you mind explaining how to calculate the exit radiance per color channel? the way I'd do it is to store, in addition to the lightmap, a "vector map" containing a weighted average of the lights afecting that particular texel, the weights would look something like (Bj * Fij) where Bj is the emitter's radiance flux and Fij is the form factor between i and j. at run time, I'd just dot the "vector map" with the normal map, and modulate with the lightmap. thanks. Original Message From: Paul_Firth@... [mailto:Paul_Firth@...]=20 Sent: Thursday, April 15, 2004 1:45 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" On 14/04/2004 18:17:53 gdalgorithmslistadmin wrote:=20 >Hi Paul, >=20 > what do you mean by "coloured" bumpmaps? You're computing the exit radiance for each texel's colour channel as a=20 vector, giving three bumpmaps in total for coloured lighting, for greyscale you only have one. Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@... This footnote also confirms that this email message has been checked for all known viruses. ********************************************************************** SCEE 2004  This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Andy Sloane <andy@gu...>  20040415 17:21:03

Hello, For various reasons, I would like a quick capsuleoriented box test. Intuitively, this is equivalent to a line segmentoriented box separating axis test, except the line segment is 'inflated' by the radius when it is projected onto any axis. The obvious choices are the axes of the box itself, the axis of the line segment, and the cross product of the latter with the former three, so seven in all. Is that it? Is that too many? More generally, one thing I'm having trouble with is that I'm not really sure how to select an axis to represent a nearcollision between the vertex of the line segment and a vertex of the box. The segmentbox test on magicsoftware (http://www.magicsoftware.com/Source/Intersection/WmlIntrLin3Box3.cpp) utterly confounds me after the first three axes are tested. The cross product of the difference between centers and the axis of the line segment is taken, but I don't understand what's going on with the three tests after that; I can't wrap my head around the geometry. Andy 
From: Emanuele Salvucci <info@fo...>  20040415 16:09:39

As far as I can observe from the slides, all the 3 lightmaps have RGB values each...and I assume they're "weighted" at each pixel considering the vector basis. (offline) "Bumpmaps" are normal maps...and they're "dotted" with the vector basis and multiplied with all three lightmaps. (each) This "realtime compositing" pipeline is quite similar to ours. Best, Emanuele.  Original Message  From: <Paul_Firth@...> To: <gdalgorithmslist@...> Sent: Thursday, April 15, 2004 10:44 AM Subject: Re: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" > On 14/04/2004 18:17:53 gdalgorithmslistadmin wrote: > > >Hi Paul, > > > > what do you mean by "coloured" bumpmaps? > > You're computing the exit radiance for each texel's colour channel as a > vector, giving three bumpmaps in total for > coloured lighting, for greyscale you only have one. > > Cheers, Paul. > > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > postmaster@... > > This footnote also confirms that this email message has been checked > for all known viruses. > > ********************************************************************** > SCEE 2004 > > > >  > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Paul_F<irth@sc...>  20040415 08:45:07

On 14/04/2004 18:17:53 gdalgorithmslistadmin wrote: >Hi Paul, > > what do you mean by "coloured" bumpmaps? You're computing the exit radiance for each texel's colour channel as a vector, giving three bumpmaps in total for coloured lighting, for greyscale you only have one. Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@... This footnote also confirms that this email message has been checked for all known viruses. ********************************************************************** SCEE 2004 
From: Tom Forsyth <tom.forsyth@ee...>  20040415 06:02:23

That page will shortly die (I moved countries!). This page is now at http://www.eelpi.gotdns.org/papers.html TomF. > From: Megan Fox >=20 > TomF's explanation of this usage of SH's is excellent: > http://www.tomforsyth.pwp.blueyonder.co.uk/papers.html >=20 > What game(s) are currently using this tech, though? =20 > (assuming you can say) >=20 > Megan Fox >=20 > > There is at least one game that already used SH to=20 > represent "irradiance > > volumes", this is very different than using PRT (if you=20 > just use linear > > SH it is cheaper than the "ambient cube" used in HL2  4=20 > colors/basis > > functions instead of 6 and you only need 3 instructions=20 > (all mad's). It > > represents a smoother (but alias free!) ambient=20 > approximation compared > > to HL2.) > > > > I think SH shouldn't be confused with PRT (which is clearly heavier > > weight.) > > > > PeterPike > > > > (The perfect reconstruction of constants using the squared basis > > functions is nice  I hadn't realized that at first... One=20 > vanishing > > moment is better than none  so the "ambient cube" has no=20 > aliasing for > > constant illumination...) > > > > Original Message > > From: gdalgorithmslistadmin@... > > [mailto:gdalgorithmslistadmin@...] On Behalf Of > > Emanuele Salvucci > > Sent: Wednesday, April 14, 2004 10:12 AM > > To: gdalgorithmslist@... > > Subject: Re: [Algorithms] low order SH vs Half Life 2=20 > "Radiosity Normal > > Mapping" > > > > The point of Radiosity Normal Mapping is to achieve "tiled=20 > detail" given > > by normal maps on GI lightmaps, which are generated out of lowres > > meshes. > > (what do you mean by lowres lightmaps?...we can use as much as 300+ > > lightmaps 24bits 512x512 on a single load...using 54Mb of=20 > Vram which on > > a surface of 1 sqKm gives a resolution of 78.643 pixels/sqMeter) > > > > If you want...you can pretty much put just pure GI data into your > > lightmap and leave direct lighting with dynamic=20 > techniques...which gives > > you that you can animate those lights. (GI won't be affected though) > > > > Obviously you won't get the "open the door and let the radiosity > > be"effect, this way. > > But AFAIK I didn't see any similar example using SH yet...=20 > and the ones > > around aren't very much applicable to "today's" games, IMHO. > > ...I'd give fullsceneSH practical gameapplications=20 > another couple of > > "boards generations". ;) > > > > > > Best, > > > > Emanuele. > > > >  Original Message  > > From: "Sebastian Tusk" <s.tusk@...> > > To: <gdalgorithmslist@...> > > Sent: Wednesday, April 14, 2004 5:10 PM > > Subject: Re: [Algorithms] low order SH vs Half Life 2=20 > "Radiosity Normal > > Mapping" > > > > > > > > Or should i abandon SH right now and just pursue this=20 > much simpler > > method? :) > > > > > > Isn't SH about dynamic global illumination? Where this HL2 paper > > > describes a method to get more detail from lowres=20 > lightmaps for static > > > > > lighting. Or is there a misconception on my side? > > > > > > Sebastian > > > > > > > > > > > >  > > > This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux > > > tutorial presented by Daniel Robbins, President and CEO of GenToo > > > technologies. Learn everything from fundamentals to system > > >=20 > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > > > _______________________________________________ > > > GDAlgorithmslist mailing list > > > GDAlgorithmslist@... > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > > > > > > > > >  > > This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux > > tutorial presented by Daniel Robbins, President and CEO of GenToo > > technologies. Learn everything from fundamentals to system > >=20 > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > > > >  > > This SF.Net email is sponsored by: IBM Linux Tutorials > > Free Linux tutorial presented by Daniel Robbins, President=20 > and CEO of > > GenToo technologies. Learn everything from fundamentals to system > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > > >=20 >=20 >=20 >  > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 