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
(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: PeterPike Sloan <ppsloan@wi...>  20040416 21:37:31

I think pauls technique is even lighter weight. From what I understand he just has 3 dot products. I believe paul is basically using the "vector irradiance" instead of plain old irradiance. Andrew Wilmott talks about this in his thesis (and arvo used it in earlier work as well...) Both techniques are kind of doing this, they are just using different basis... Paul stores a vector per color channel and then just dots this with the normal from the normal map. While garys basis function are fixed in tangent space (and higher order), pauls are "specialized" for the given lighting environment. Pauls vectors represent both the magnitude and direction in his 3 textures. To make things conceptually similar (colors wrt basis functions), here is what I believe pauls basis is: R =3D dot(N,Vr); G =3D dot(N,Vg); B =3D dot(N,Vb); Where RGB is the desired color, N is the normal from the normal map and Vr is the "red" vector (in tangent space), Vg/Vb "green"/"blue" respectively. This is equivalent to: N.x * (Vr.x,Vg.x,Vb.x) + N.y * (Vr.y, Vg.y, Vb.y) + N.z * (Vr.z, Vg.z, Vb.z) So basis functions being X/Y/Z axis and colors (coefficients) being the respective 3 tuples above. He couldn't use ATI's compression scheme unless he factored the intensity out of the basis functions... PeterPike (This is basically the same thing as garys linear slide  modulo saturation issues...) Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Gary McTaggart Sent: Friday, April 16, 2004 12:22 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" Each lightmap has a color value that represents incoming lighting data for three different directions. There is a single tangent space normal map. We don't actually compress our lightmaps since we update them dynamically in some cases (switcahble lights/flickering lights. .these work really well with this technique). We have 910MB of uncompressed lightmap data in a typical level. Here are the slides:=20 http://www.ati.com/developer/gdc/D3DTutorial10_HalfLife2_Shading.pdf One correction to the slides is that: float3 diffuseLighting =3D=20 saturate( dot( normal, bumpBasis[0] ) ) * lightmapColor1 + saturate( dot( normal, bumpBasis[1] ) ) * lightmapColor2 + saturate( dot( normal, bumpBasis[2] ) ) * lightmapColor3; should be: float d[3]; d[0] =3D saturate( dot( normal, bumpBasis[0] ) ); d[1] =3D saturate( = dot( normal, bumpBasis[1] ) ); d[2] =3D saturate( dot( normal, bumpBasis[2] ) ); float3 diffuseLighting =3D=20 ( d[0] * d[0] ) * lightmapColor1 + ( d[1] * d[1] ) * lightmapColor2 + ( d[2] * d[2] ) * lightmapColor3; A really good thing about this technique is that this equation is expressible in a ps_1_1 shader. Can you explain your technique more? On a related note, there is a good white paper on alternate normal map compression schemes on ATI's page. Gary > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On Behalf Of=20 > Paul_Firth@... > Sent: Friday, April 16, 2004 5:43 AM > To: gdalgorithmslist@... > Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity=20 > Normal Ma pping" >=20 > On 16/04/2004 14:33:52 gdalgorithmslistadmin wrote:=20 >=20 > >Paul_Firth@... writes: > > > If you use tangent space normal maps (as opposed to world space),=20 > > > palletisation will take care of that problem, I should > think. Or at > > > least I thought that was the latest thinking regarding > compressing > > > normal maps... :) > >=20 > > Palettes are not supported by the latest crop of hardware, and=20 > > unlikely to be in the future. You can emulate them in the > pixel shader > > with a dependent texture read, but that gets very expensive for=20 > > anything more than point sampling (8 texture lookups for bilinear!). > >=20 > > For all practical purposes, palettes are a think of the past on the=20 > > GPU side, leaving various DXT encodings as the only really > practical > > way of compressing normalmaps. >=20 > Thats a shame, palettes were cool. >=20 > Ah well. Can anyone point out the differences in these two techniques, > then (i.e. mine and Gary's)  I assume the lightmaps in Gary's=20 > technique must represent scalars rather than vectors? >=20 > Cheers, Paul. >=20 >=20 > ********************************************************************** > This email and any files transmitted with it are confidential and=20 > intended solely for the use of the individual or entity to whom they=20 > are addressed. If you have received this email in error please notify=20 > postmaster@... >=20 > This footnote also confirms that this email message has been checked=20 > for all known viruses. >=20 > ********************************************************************** > SCEE 2004 >=20 >=20 >=20 >  > This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux=20 > tutorial presented by Daniel Robbins, President and CEO of GenToo=20 > 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 >=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=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: Gary McTaggart <gary@va...>  20040416 19:21:30

Each lightmap has a color value that represents incoming lighting data for three different directions. There is a single tangent space normal map. We don't actually compress our lightmaps since we update them dynamically in some cases (switcahble lights/flickering lights. .these work really well with this technique). We have 910MB of uncompressed lightmap data in a typical level. Here are the slides:=20 http://www.ati.com/developer/gdc/D3DTutorial10_HalfLife2_Shading.pdf One correction to the slides is that: float3 diffuseLighting =3D=20 saturate( dot( normal, bumpBasis[0] ) ) * lightmapColor1 + saturate( dot( normal, bumpBasis[1] ) ) * lightmapColor2 + saturate( dot( normal, bumpBasis[2] ) ) * lightmapColor3; should be: float d[3]; d[0] =3D saturate( dot( normal, bumpBasis[0] ) ); d[1] =3D saturate( dot( normal, bumpBasis[1] ) ); d[2] =3D saturate( dot( normal, bumpBasis[2] ) ); float3 diffuseLighting =3D=20 ( d[0] * d[0] ) * lightmapColor1 + ( d[1] * d[1] ) * lightmapColor2 + ( d[2] * d[2] ) * lightmapColor3; A really good thing about this technique is that this equation is expressible in a ps_1_1 shader. Can you explain your technique more? On a related note, there is a good white paper on alternate normal map compression schemes on ATI's page. Gary > Original Message > From: gdalgorithmslistadmin@...=20 > [mailto:gdalgorithmslistadmin@...] On=20 > Behalf Of Paul_Firth@... > Sent: Friday, April 16, 2004 5:43 AM > To: gdalgorithmslist@... > Subject: RE: [Algorithms] low order SH vs Half Life 2=20 > "Radiosity Normal Ma pping" >=20 > On 16/04/2004 14:33:52 gdalgorithmslistadmin wrote:=20 >=20 > >Paul_Firth@... writes: > > > If you use tangent space normal maps (as opposed to world space),=20 > > > palletisation will take care of that problem, I should=20 > think. Or at=20 > > > least I thought that was the latest thinking regarding=20 > compressing=20 > > > normal maps... :) > >=20 > > Palettes are not supported by the latest crop of hardware, and=20 > > unlikely to be in the future. You can emulate them in the=20 > pixel shader=20 > > with a dependent texture read, but that gets very expensive for=20 > > anything more than point sampling (8 texture lookups for bilinear!). > >=20 > > For all practical purposes, palettes are a think of the past on the=20 > > GPU side, leaving various DXT encodings as the only really=20 > practical=20 > > way of compressing normalmaps. >=20 > Thats a shame, palettes were cool. >=20 > Ah well. Can anyone point out the differences in these two=20 > techniques, then (i.e. mine and Gary's)  I assume the=20 > lightmaps in Gary's technique must represent scalars rather=20 > than vectors? >=20 > Cheers, Paul. >=20 >=20 > ********************************************************************** > This email and any files transmitted with it are confidential=20 > and intended solely for the use of the individual or entity=20 > to whom they are addressed. If you have received this email=20 > in error please notify postmaster@... >=20 > This footnote also confirms that this email message has been=20 > checked for all known viruses. >=20 > ********************************************************************** > SCEE 2004 >=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: Alen Ladavac <alenlml@cr...>  20040416 15:03:05

Actually, it is not that hard to do a proper separating axis test. The axes are: 1) 3 cross products of box axes with capsule main axis direction (to test edges to capsule cylinder), 2) 8 directions of lines perpendicular to capsule main axis, passing through each of the box vertices (to test vertices to capsule cylinder, actually catches the faces agains capsule cylinder as a side effect), 3) 2 "Arvo's axes", one for each capsule sphere (this catches capsule caps against anything on the cube). What I like to call "Arvo's axis" is what you get from the Arvo's algorithm if you track actual direction vector instead of distance. Note that you cannot just do Arvo's algo for both spheres because you cannot get any useful result from that for the entire capsule (at least I didn't find any), so you need to find the axis resulting from it and then do a usual separating axis test. Whether this classifies as a "pure" separating axis approach or not, I don't know. But I'm sure it does the work, and with a reasonable number of axes. ;) HTH, Alen 
From: <Paul_Firth@sc...>  20040416 13:42:55

On 16/04/2004 14:33:52 gdalgorithmslistadmin wrote: >Paul_Firth@... writes: > > If you use tangent space normal maps (as opposed to world space), > > palletisation will take care of that problem, I should think. Or > > at least I thought that was the latest thinking regarding > > compressing normal maps... :) > > Palettes are not supported by the latest crop of hardware, and unlikely > to be in the future. You can emulate them in the pixel shader with > a dependent texture read, but that gets very expensive for anything > more than point sampling (8 texture lookups for bilinear!). > > For all practical purposes, palettes are a think of the past on the > GPU side, leaving various DXT encodings as the only really practical > way of compressing normalmaps. Thats a shame, palettes were cool. Ah well. Can anyone point out the differences in these two techniques, then (i.e. mine and Gary's)  I assume the lightmaps in Gary's technique must represent scalars rather than vectors? 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: Emanuele Salvucci <info@fo...>  20040416 13:39:22

 Original Message  From: <Paul_Firth@...> To: <gdalgorithmslist@...> Sent: Friday, April 16, 2004 3:22 PM Subject: Re: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" > On 16/04/2004 13:20:42 gdalgorithmslistadmin wrote: > > But nowadays... DXT compression is almost a "musthave". > > If you use tangent space normal maps (as opposed to world space), > palletisation > will take care of that problem, I should think. Or at least I thought that > was the latest > thinking regarding compressing normal maps... :) > > Cheers, Paul. > Yup, I was considering tangent space normal maps. Unless you want to save just little using other subformats (DXT3, DXT5...etc.), DXT1 method is the only one giving a compression ratio of 6:1... which means a 1024x1024 normal map can take as little as 680K mips included. (out of the original 3 Mb image) With the updated Nvidia exporter for Photoshop quality has been quite improved, but you still, unavoidably, lose data. A good compromise, IMHO, is to use quite big n.maps, 1024 for instance, and use DXT1... so you kind of balance the loss with resolution. (which isn't a "real gain", rather a practical one... as you don't avoid quantization artifacts anyway) Best, Emanuele. 
From: Shawn Hargreaves <shargreaves@cl...>  20040416 13:34:08

Paul_Firth@... writes: > If you use tangent space normal maps (as opposed to world space), > palletisation will take care of that problem, I should think. Or > at least I thought that was the latest thinking regarding > compressing normal maps... :) Palettes are not supported by the latest crop of hardware, and unlikely to be in the future. You can emulate them in the pixel shader with a dependent texture read, but that gets very expensive for anything more than point sampling (8 texture lookups for bilinear!). For all practical purposes, palettes are a think of the past on the GPU side, leaving various DXT encodings as the only really practical way of compressing normalmaps.  Shawn Hargreaves Climax Brighton 
From: <Paul_Firth@sc...>  20040416 13:22:20

On 16/04/2004 13:20:42 gdalgorithmslistadmin wrote: >Ok, now that I have a better understanding of your alternative... I can just > notice one thing. > > 3 compressed lightmaps are better than 3 compressed normal maps. > > Normal map compression (DXT) doesn't perform as well as for other types. > Since these lightmaps are lowfrequency, you won't lose much by compressing > them...while you lose quite a lot on normal maps...especially because > compression artifacts translate in "wrong vectors"...and by having 3 "quite > wrong" vectors I don't think you end up enhancing the result, but possibly > degrading it. > > ...obviously if you don't use compression...then it's a different matter. ;) > But nowadays... DXT compression is almost a "musthave". If you use tangent space normal maps (as opposed to world space), palletisation will take care of that problem, I should think. Or at least I thought that was the latest thinking regarding compressing normal maps... :) 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: Emanuele Salvucci <info@fo...>  20040416 12:20:52

Ok, now that I have a better understanding of your alternative... I can just notice one thing. 3 compressed lightmaps are better than 3 compressed normal maps. Normal map compression (DXT) doesn't perform as well as for other types. Since these lightmaps are lowfrequency, you won't lose much by compressing them...while you lose quite a lot on normal maps...especially because compression artifacts translate in "wrong vectors"...and by having 3 "quite wrong" vectors I don't think you end up enhancing the result, but possibly degrading it. ...obviously if you don't use compression...then it's a different matter. ;) But nowadays... DXT compression is almost a "musthave". Best, Emanuele.  Original Message  From: <Paul_Firth@...> To: <gdalgorithmslist@...> Sent: Friday, April 16, 2004 11:41 AM Subject: Re: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" > On 16/04/2004 10:36:13 gdalgorithmslistadmin wrote: > > >...finally... thanks Paul... it really didn't need all that formulas to > > explain the procedure!;) > > > > But you mentioned again "3 normal maps"...which isn't... it's 3 > lightmaps > > and 1 normal map. (right Gary?) > > We may be talking about different things. I'm not trying to explain how > Gary's > technique works, I'm potentially explaining something else which might > also > look quite nice ;) > > 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: Emanuele Salvucci <info@fo...>  20040416 10:02:52

Uh, sorry then... I'll read back and find out the root of your different path on this discussion... ;) ...as it's taking many different directions.. :O ;) Best, Emanuele.  Original Message  From: <Paul_Firth@...> To: <gdalgorithmslist@...> Sent: Friday, April 16, 2004 11:41 AM Subject: Re: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" > On 16/04/2004 10:36:13 gdalgorithmslistadmin wrote: > > >...finally... thanks Paul... it really didn't need all that formulas to > > explain the procedure!;) > > > > But you mentioned again "3 normal maps"...which isn't... it's 3 > lightmaps > > and 1 normal map. (right Gary?) > > We may be talking about different things. I'm not trying to explain how > Gary's > technique works, I'm potentially explaining something else which might > also > look quite nice ;) > > 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_Firth@sc...>  20040416 09:41:31

On 16/04/2004 10:36:13 gdalgorithmslistadmin wrote: >...finally... thanks Paul... it really didn't need all that formulas to > explain the procedure!;) > > But you mentioned again "3 normal maps"...which isn't... it's 3 lightmaps > and 1 normal map. (right Gary?) We may be talking about different things. I'm not trying to explain how Gary's technique works, I'm potentially explaining something else which might also look quite nice ;) 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: Emanuele Salvucci <info@fo...>  20040416 09:36:21

...finally... thanks Paul... it really didn't need all that formulas to explain the procedure!;) But you mentioned again "3 normal maps"...which isn't... it's 3 lightmaps and 1 normal map. (right Gary?) Best, Emanuele.  Original Message  From: <Paul_Firth@...> To: <gdalgorithmslist@...> Sent: Friday, April 16, 2004 11:03 AM Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" > On 15/04/2004 18:30:22 gdalgorithmslistadmin wrote: > > >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. > > Its nothing that complicated. You have your light transport monte carlo > raytracer (or similar) calculate all the (potential) outgoing light at > each > texel as the avarage of all the outgoing light directions (i.e. > reflected/occluded > incoming light vectors) but you do it for each colour channel, so you have > the avarage of all exiting radiance as a vector for each of r g and b. > > Then you take your three bumpmaps ( I guess you have to be carful here > about > the range of intensity in those maps since >255 is not allowed) at runtime > and dot the light's colour channels against the precomputed maps > and voila. > > 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_Firth@sc...>  20040416 09:17:32

On 15/04/2004 18:30:22 gdalgorithmslistadmin wrote: >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. ...of course, when I say bumpmaps, I mean normalmaps. ;) 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: <Paul_Firth@sc...>  20040416 09:03:53

On 15/04/2004 18:30:22 gdalgorithmslistadmin wrote: >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. Its nothing that complicated. You have your light transport monte carlo raytracer (or similar) calculate all the (potential) outgoing light at each texel as the avarage of all the outgoing light directions (i.e. reflected/occluded incoming light vectors) but you do it for each colour channel, so you have the avarage of all exiting radiance as a vector for each of r g and b. Then you take your three bumpmaps ( I guess you have to be carful here about the range of intensity in those maps since >255 is not allowed) at runtime and dot the light's colour channels against the precomputed maps and voila. 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: Gino van den Bergen <gvandenbergen@pl...>  20040416 08:55:04

A "pure" separating axis approach is not applicable here, since you can not restrict the potential separating axes to the face orientations and cross products of edge directions, as with polytopes. You solve this problem by computing the (squared) distance of the line segment and the box. (If the distance is greater than the capsules radius, the objects do not intersect.) The witness points of the distance, i.e. the closest points, construct a separating axis (or conincide in case of an intersection).=20 You can use GJK for computing the distance between a line segment and a box (my favorite hammer). However, in this case an explicit "construction" of the Minkowski sum of the line segment and the box might be faster (although I'd doubt it). Simply, construct all the supporting planes (a x + b y + c z + d =3D 0, normal n =3D (a, b, c)^T pointing outward) of faces of the Minkowski sum. These are (a) Faces of the box offset by Max(dot(n, p), dot(n, q)) where p and q are endpoints of the line segment. 6 in total. (b) Cross products of the direction (p  q) and the box's principle axes offset by the vertices. Also 6 in total. =20 See a pattern? These correspond with the potential separating axes in the separating axes method. Each axis results in two parallel planes. Next, find the closest point to the origin of the rhombic dodecahedron formed by these 12 planes. Planes for which the origin lies on the negative side (plane offset d is negative) are immediately discarded. So, now are left with at most 6 planes. Select the furthest plane (the plane for which d is the largest, if we normalized all normals). Compute the closest point on this plane and check whether it lies inside all other halfspaces. If it does, then this is your closest point. If not, then compute the line of intersection of the furthest plane and the violating plane, and compute the closest point on this line. Perform the same check for the remaining (at most 4) faces, and compute the point of intersection of the line and the violating plane if one exists.=20 There you have it. The closest point is your separating axis, and its distance to the origin is the distance between the line segment and the box. As said, I would not put my money on this routine being faster than GJK for the general case, but at least it can be parallelized a little easier. =20 Gino van den Bergen http://www.dtecta.com Original Message From: Andy Sloane [mailto:andy@...]=20 Sent: Thursday, April 15, 2004 22:48 To: gdalgorithmslist@... Subject: Re: [Algorithms] CapsuleOBB separating axes > 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 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). =20 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  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: Gary McTaggart <gary@va...>  20040416 05:39:43

We do all of our lighting calculations in our radiosity simulator down to the point where we dot the surface normal against incoming light direction and do this three times instead of one. Gary Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of PeterPike Sloan Sent: Thursday, April 15, 2004 1:27 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] low order SH vs Half Life 2 "Radiosity Normal Mapping" 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  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 