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}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(2) 
2

3
(6) 
4
(3) 
5
(9) 
6
(12) 
7
(54) 
8
(17) 
9
(7) 
10
(18) 
11
(13) 
12
(17) 
13
(22) 
14
(6) 
15
(3) 
16
(1) 
17
(3) 
18
(4) 
19
(6) 
20
(9) 
21
(3) 
22

23

24

25

26

27
(2) 
28
(4) 
29

30
(7) 
31
(21) 





From: Jonathan Blow <jon@nu...>  20050119 22:37:09

>Could you explain a little bit more that point ? >I do not understand why the way to of storing NM can=20 >influence the artistic process. > =20 > Artists like drawing normal maps as height fields, because it's easier=20 to think about and it's what a lot of packages support by default (e.g.=20 3dsmax). So if your texture format needs to be rgb normal map to=20 render, then you either have to convert to that texture format in the=20 external toolchain (so that it's a normal map on disk and not a height=20 field), or you need to load the height field at runtime and then convert=20 it. The former option is a pain in the ass because it's another step in=20 your toolchain and it makes things like hotloading more difficult. The=20 latter option is more reasonable  you could have your normal map=20 loader look for height fields and convert them automatically at load=20 time, and hotloading just works. This adds just a bit of code to your=20 runtime, however.... Suppose you want to build a normal map "quasiprocedurally" by layering=20 two maps together at different scales. When the scale factors refer to=20 a height field, and you're just multiplying and adding the maps=20 together, then building normals from that, it is pretty easy for the=20 artist to visualize what that means, and to work with it. If they are=20 stored on disk or in memory as actual normals, and you are trying to=20 combine them.... well, it's not the same thing. This is sucky. Better if you can just render heightfields, and you just composite the=20 textures in the pixel shader. >In fact, I always thought it was a matter of how much >complex the normal map is (normal variation / depth >of the heightfield). >* for low variation, heightfield is ok >* for medium variation, storing only X/Y (and Z=3Dsqrt(X=B2+Y=B2), which >can be computed in hardware. >* for large scale variation, one must use the full 3 chanels. > =20 > Sure, I've heard lots of things like this, but we've all heard technical=20 information that was not wellfounded, so it's hard to know how much=20 verity to ascribe to this. I am hoping to hear from someone who is a=20 good programmer and has spent a lot of time working on this. One can=20 dream, anyway. 
From: <gabriel.peyre@gm...>  20050119 20:16:15

> it would solve a lot of things > (simpler art path, etc). Could you explain a little bit more that point ? I do not understand why the way to of storing NM can=20 influence the artistic process. Also, depending on how much complex the NM is,=20 one can switch=20 RVB normal map<>Grayscale heightfield without too much distortion (whatever tool was used to create the original map). In fact, I always thought it was a matter of how much complex the normal map is (normal variation / depth of the heightfield). * for low variation, heightfield is ok * for medium variation, storing only X/Y (and Z=3Dsqrt(X=B2+Y=B2), which can be computed in hardware. * for large scale variation, one must use the full 3 chanels. Gabriel 
From: Jonathan Blow <jon@nu...>  20050119 09:40:10

This is something I am kind of pondering right now... I am tempted to try out using heightfields directly since it would solve a lot of things (simpler art path, etc). Has anyone done it? Tom Forsyth wrote: >Always wondered how much better or worse storing heightfields was than >storing the normalmap. Got any comments on that, Jason? Pluses, minuses, >etc? > >TomF. > > >Original Message >From: gdalgorithmslistadmin@... >[mailto:gdalgorithmslistadmin@...] On Behalf Of Jason >Mitchell >Sent: 18 January 2005 10:39 >To: 'gdalgorithmslist@...' >Subject: RE: [Algorithms] Regular grid's vertex normals > > > > > The Sobel filter can be used to compute the gradient of a height field >with respect to x and y, which one generally assumes to be perpendicular to >the normal. Hence, their cross product is the normal you're after. Below >is an HLSL function I use to compute a normal map from a height map on the >GPU: >// Run sobel filters over height map to compute normals >float4 ps_compute_normals( float2 Tex : TEXCOORD0 ) : COLOR0 >{ > // This epsilon is a function of the size of the > // texture and should be set properly by app > float e = g_fTexelSize; > // Damping factor > float fDamp = 0.4f; > // Take all eight taps > float tl = fDamp * abs(tex2D (aSamp, Tex + float2(e, e))); // top >left > float l = fDamp * abs(tex2D (aSamp, Tex + float2(e, 0))); // left > float bl = fDamp * abs(tex2D (aSamp, Tex + float2(e, e))); // bottom >left > float t = fDamp * abs(tex2D (aSamp, Tex + float2( 0, e))); // top > float b = fDamp * abs(tex2D (aSamp, Tex + float2( 0, e))); // bottom > float tr = fDamp * abs(tex2D (aSamp, Tex + float2( e, e))); // top >right > float r = fDamp * abs(tex2D (aSamp, Tex + float2( e, 0))); // right > float br = fDamp * abs(tex2D (aSamp, Tex + float2( e, e))); // bottom >right > // Compute dx using Sobel: > // > // 1 0 1 > // 2 0 2 > // 1 0 1 > float dX = tl  2.0f*l  bl + tr + 2.0f*r + br; > // Compute dy using Sobel: > // > // 1 2 1 > // 0 0 0 > // 1 2 1 > float dY = tl  2.0f*t  tr + bl + 2.0f*b + br; > // Compute crossproduct and renormalize (flip dX for correct handedness) > > float4 N = float4(normalize(float3(dX, dY, 1)), 1.0f); > // Bias signed values from 1..1 to 0..1 range > return N * 0.5f + 0.5f; >} > > > >Original Message >From: Drizzt [mailto:drizzt.du@...] >Sent: Tuesday, January 18, 2005 3:29 AM >To: GDAlgorithmslist@... >Subject: [Algorithms] Regular grid's vertex normals > > >Hi all. >While looking around on the net, I've found a few messages here and there >referring to a way to fast compute normals over a regular triangle grid, >something connected to the name "Sobel". Problem is that I've not been able >to find something about it...someone has a link or something? >Thx! > > 
From: Wolfgang Engel <wolfgang.engel@we...>  20050119 07:11:58

Hi, I implemented OrenNayar in a ps_2_0 pixel shader with a lookup table (L16) for the term sin(a) * tan(b). Roughness can be set per pixel by using a roughness map, which is the alpha channel of another map. As Peter said, clamping values by using saturate() or min()/max() is always a good idea. This lighting algorithm is used to mimic cloth material in our first prototypes of the main game character. If you replace the diffuse term N.L with OrenNayar in your lighting formula, the bump mapping effect will be "absorbed" depending on the roughness value. So our artists do not see the bump mapping effect anymore. I like the level of control and the nice distribution of light, but it looks like we will end up with N.L.  Wolf Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Igor Kravtchenko Sent: Wednesday, January 19, 2005 12:16 AM To: gdalgorithmslist@... Subject: [Algorithms] Oren Nayar lighting Hi, I'm currently implementing a Oren Nayar lighting model and I'm encountering a problem with the original equation. I recall the formula: i =3D base_color * NdotL * [A + B * max(0, cos(trti) * sin(a) * tan(b)] And my problem is about that tan(b). b is either the angle between light and normal or the angle between view and normal. It's just the smallest of both. For faces that have their normal almost parallel with the view plane it happens this angle (which is then ~90=B0) is lesser than the angle = between the light and the normal. In such case, since we take the minimum angle we make a tan(b) with b ~=3D 90=B0. That gives a huge result that tends = to infinity and causes the color to be totally saturated. In other words, all the meshes are saturated for faces which tend to be perpendicular to the view plane. The trick I've found is to modulate the result with max(0, NdotL) instead of NdotL. Indeed if the angle between light and normal is so big that is greater than 90=B0, the face backfaces the light and we cancel = the big tan(b) result by 0. It seems to solve the problem. However I had a look at 2 implementations. http://www.gamasutra.com/features/20030514/fosner_03.shtml and the one used in RenderMan: http://groups.google.fr/groups?hl=3Dfr&lr=3D&threadm=3D3B090E86.6241AB67%= 40hol ypixel.com&rnum=3D2&prev=3D/groups%3Fq%3Doren%2Bnayar%2Bshader%26hl%3Dfr%= 26l r%3D%26selm%3D3B090E86.6241AB67%2540holypixel.com%26rnum%3D2 and none of them seem to perform that operation. Am I missing something fundamental here? Also I would be interested to heard about people who implemented an Oren Nayar lighting model. My implementation uses v/f program and seems coherent. We can reproduce pretty easily the famous "moon effect" or velvet rendering. However by comparing with a render made under 3DS MAX, it's not totally the same thing. MAX seems to have a less soft "intensity range" (I could show better by taking some screenshots). Are yours have identical rendering than MAX? Any hint or remark would be greatly appreciated, Igor.  The SF.Net email is sponsored by: Beat the postholiday blues Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. It's fun and FREE  well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Tom Forsyth <tom.forsyth@ee...>  20050119 04:23:01

Always wondered how much better or worse storing heightfields was than storing the normalmap. Got any comments on that, Jason? Pluses, = minuses, etc? TomF. Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of = Jason Mitchell Sent: 18 January 2005 10:39 To: 'gdalgorithmslist@...' Subject: RE: [Algorithms] Regular grid's vertex normals The Sobel filter can be used to compute the gradient of a height = field with respect to x and y, which one generally assumes to be perpendicular = to the normal. Hence, their cross product is the normal you're after. = Below is an HLSL function I use to compute a normal map from a height map on = the GPU: // Run sobel filters over height map to compute normals=20 float4 ps_compute_normals( float2 Tex : TEXCOORD0 ) : COLOR0=20 {=20 // This epsilon is a function of the size of the=20 // texture and should be set properly by app=20 float e =3D g_fTexelSize;=20 // Damping factor=20 float fDamp =3D 0.4f;=20 // Take all eight taps=20 float tl =3D fDamp * abs(tex2D (aSamp, Tex + float2(e, e))); // = top left=20 float l =3D fDamp * abs(tex2D (aSamp, Tex + float2(e, 0))); // = left=20 float bl =3D fDamp * abs(tex2D (aSamp, Tex + float2(e, e))); // = bottom left=20 float t =3D fDamp * abs(tex2D (aSamp, Tex + float2( 0, e))); // = top=20 float b =3D fDamp * abs(tex2D (aSamp, Tex + float2( 0, e))); // = bottom=20 float tr =3D fDamp * abs(tex2D (aSamp, Tex + float2( e, e))); // = top right=20 float r =3D fDamp * abs(tex2D (aSamp, Tex + float2( e, 0))); // = right=20 float br =3D fDamp * abs(tex2D (aSamp, Tex + float2( e, e))); // = bottom right=20 // Compute dx using Sobel:=20 //=20 // 1 0 1=20 // 2 0 2=20 // 1 0 1=20 float dX =3D tl  2.0f*l  bl + tr + 2.0f*r + br;=20 // Compute dy using Sobel:=20 //=20 // 1 2 1=20 // 0 0 0=20 // 1 2 1=20 float dY =3D tl  2.0f*t  tr + bl + 2.0f*b + br;=20 // Compute crossproduct and renormalize (flip dX for correct = handedness) float4 N =3D float4(normalize(float3(dX, dY, 1)), 1.0f);=20 // Bias signed values from 1..1 to 0..1 range=20 return N * 0.5f + 0.5f;=20 }=20 Original Message=20 From: Drizzt [mailto:drizzt.du@...]=20 Sent: Tuesday, January 18, 2005 3:29 AM=20 To: GDAlgorithmslist@...=20 Subject: [Algorithms] Regular grid's vertex normals=20 Hi all.=20 While looking around on the net, I've found a few messages here and = there referring to a way to fast compute normals over a regular triangle grid, something connected to the name "Sobel". Problem is that I've not been = able to find something about it...someone has a link or something? Thx!=20 =20 Il sole ruba i sogni=20 =20 The SF.Net email is sponsored by: Beat the postholiday blues Get a FREE limited edition SourceForge.net tshirt from ThinkGeek. It's fun and = FREE  well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________=20 GDAlgorithmslist mailing list GDAlgorithmslist@...=20 https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist=20 Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188=20 
From: PeterPike Sloan <ppsloan@wi...>  20050119 03:01:16

Any reflectance function should clamp things like you mention below  a = lot of times the BRDF is treated independently which doesn't have the = NdotL term. They also might only be invoking the reflection model when = NdotL is positive... PeterPike Sloan Original Message From: gdalgorithmslistadmin@... = [mailto:gdalgorithmslistadmin@...] On Behalf Of Igor = Kravtchenko Sent: Tuesday, January 18, 2005 3:16 PM To: gdalgorithmslist@... Subject: [Algorithms] Oren Nayar lighting Hi, I'm currently implementing a Oren Nayar lighting model and I'm = encountering a problem with the original equation. I recall the formula: i =3D base_color * NdotL * [A + B * max(0, cos(trti) * sin(a) * tan(b)] And my problem is about that tan(b). b is either the angle between light and normal or the angle between view = and normal. It's just the smallest of both. For faces that have their normal almost parallel with the view plane it = happens this angle (which is then ~90=B0) is lesser than the angle = between the light and the normal. In such case, since we take the = minimum angle we make a tan(b) with b ~=3D 90=B0. That gives a huge = result that tends to infinity and causes the color to be totally = saturated. In other words, all the meshes are saturated for faces which = tend to be perpendicular to the view plane. The trick I've found is to modulate the result with max(0, NdotL) = instead of NdotL. Indeed if the angle between light and normal is so big that is greater = than 90=B0, the face backfaces the light and we cancel the big tan(b) = result by 0. It seems to solve the problem. However I had a look at 2 implementations. http://www.gamasutra.com/features/20030514/fosner_03.shtml and the one used in RenderMan: http://groups.google.fr/groups?hl=3Dfr&lr=3D&threadm=3D3B090E86.6241AB67%= 40holypixel.com&rnum=3D2&prev=3D/groups%3Fq%3Doren%2Bnayar%2Bshader%26hl%= 3Dfr%26lr%3D%26selm%3D3B090E86.6241AB67%2540holypixel.com%26rnum%3D2 and none of them seem to perform that operation. Am I missing something fundamental here? Also I would be interested to heard about people who implemented an Oren = Nayar lighting model. My implementation uses v/f program and seems coherent. We can reproduce = pretty easily the famous "moon effect" or velvet rendering. However by = comparing with a render made under 3DS MAX, it's not totally the same = thing. MAX seems to have a less soft "intensity range" (I could show better by taking some screenshots). Are yours have identical rendering than MAX? Any hint or remark would be greatly appreciated, Igor.  The SF.Net email is sponsored by: Beat the postholiday blues Get a FREE = limited edition SourceForge.net tshirt from ThinkGeek. It's fun and FREE  well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 