Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
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}

2017 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(13) 
2
(18) 
3
(11) 
4
(11) 
5

6

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

21
(9) 
22
(9) 
23
(6) 
24
(16) 
25
(8) 
26

27

28
(4) 
29
(38) 
30
(18) 



From: Mark Wayland <Mwayland@to...>  20051123 23:56:52

Hey all, I was wondering if there were any neat tricks to rendering translucent (fading) objects (as a whole) correctly? The problem I have at the moment is that when I'm fading an object out, the render states go from ZTEST/ZWRITE to ZTEST only, causing the polygons of the object to incorrectly selfsort resulting in a nasty pop (obviously same problem when fading in). The objects themselves are sorted from back to front for perobject correct blending, but I can't afford to do that perpolygon. Any ideas? Thanks and regards, Mark 
From: Danny Kodicek <dragon@we...>  20051123 16:46:35

>It's been a while since I did anything with electromagnetism, but I was under the impression that the magnetic field is in fact a vector field (more specifically it is a divergencefree vector field), and thus talking about equipotential field lines does not make sense in the first place? The *field* is a vector, but the potential is a scalar. In any case I'm not quite clear on what this potential consists of (something to do with the work needed to push a wire through that distance, at a guess), but the basic concept seems to work. >So it seems what you are really doing is finding parametrisations of curves in space the tangents of which coincide with the magnetic field. Absolutely right. > It's also been a while since I've done anything with PDE's but I think some sort of advection scheme a la Stam might help here. You're basically solving a differential equation. Ooh  two terms I don't know. That sounds promising :) I'll look 'em up and get back to you. (I skipped most of my electromagnetism lectures too, and never understood curve integrals. I've learned more calculus in the last few weeks than I ever managed at university) Thanks Danny 
From: Willem de Boer <wdeboer@mi...>  20051123 16:16:19

It's been a while since I did anything with electromagnetism, but I was under the impression that the magnetic field is in fact a vector field (more specifically it is a divergencefree vector field), and thus talking about equipotential field lines does not make sense in the first place?=20 So it seems what you are really doing is finding parametrisations of curves in space the tangents of which coincide with the magnetic field. It's also been a while since I've done anything with PDE's but I think some sort of advection scheme a la Stam might help here. You're basically solving a differential equation. Cheers, Willem H. de Boer http://research.microsoft.com/~wdeboer Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Danny Kodicek Sent: 23 November 2005 15:02 To: gdalgorithmslist@... Subject: [Algorithms] Magnetic fields (probably OT, but maybe someone can help) Hi: apologies that this is somewhat offtopic, if anyone would prefer to mail me offlist that would be fine. I've tried a few physicsrelated forums=20 (and a couple of physics professors too), but haven't had much success, and=20 I think people here may be more willing to be creative with it. The problem I'm working on is to calculate the magnetic field lines in an=20 electric motor. I've got two bar magnets arranged poletopole and a wire=20 loop between them. I'm considering it as a 2D problem only. I know how to=20 calculate the field at any one point (which I'm doing by considering the magnets as a set of dipoles). (Quick physical explanation) A magnetic field line is a line of=20 equipotential, which can be calculated by taking any point, moving a short=20 distance in the direction of the field, and repeating until one has a loop=20 (which should theoretically always happen, as there are no magnetic=20 monopoles). The field lines are drawn a constant potential distance apart,=20 which can be done by taking any curve in the space, integrating the normal=20 component of field strength along the line, and drawing a line each time this reaches a constant multiple of some value. So here's my problem: If I take a point and draw the field line from that=20 point, if the line gets too close to a currentcarrying wire it gets caught=20 in the wire's field and starts to spiral in towards the centre, which is physically impossible. I've tried various methods for correcting for the error, from increasing the resolution of my field lines (no effect) to=20 forcibly pushing the lines out of the way (the warping is obvious and I end=20 up with lines getting crossed). I've also tried an alternative approach, which is to calculate the lines by using the integration method from a=20 single reference line, or a line at infinity, but unfortunately while this=20 removes the loops, it creates lines which are clearly heading in the wrong=20 direction (sometimes even perpendicular to the field at some points). So can anyone suggest some method for correcting the problem? I'm not=20 looking for the *correct* answer, just one that *looks* correct, so any=20 algorithm that might tweak the existing answer would be interesting. My suspicion is that what I *really* need to do is fix the underlying error=20 that makes the lines spiral in the first place. I'm thinking that the wires=20 are acting kind of like a sink, and I need to add some field to them which=20 will counteract this effect. But I'm not sure how I can measure the error to=20 correct for it. Thanks for any insights Danny  This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=3D7628&alloc_id=3D16845&op=3Dclick _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Stephen Waits <steve@wa...>  20051123 15:49:52

Hello Jim, Your message entitled "[Algorithms] LinearZ && w < 0" was sent in reply to a message with a different subject. You probably intended to start a new thread; however, your mailer, like most MUAs, tricked you by including a References: header field which points back to the original message. Therefore, your new message is still threaded under the original subject, instead of your new subject. Unfortunately, this can cause your message to get lost in a completely unrelated thread! In the future, if you'd like to start a new thread, please compose a NEW message to gdalgorithmslist@... Thank you for your time and consideration.. Sincerely, Steve 
From: Jim Offerman <jofferman@ni...>  20051123 15:44:33

Hi guys, We're using linearz (as described here: http://www.mvps.org/directx/articles/linear_z/linearz.htm) to render our shadow maps. For reference, this is the shader code that is used to get linearz: float4 vPos = mul(Input.Pos,worldViewProj); vPos.z = vPos.z * vPos.w; Output.Pos = vPos; (additionally, the projection matrix has been modified so that the farplane is scaled to 1) It works perfectly in most cases, but we're having some problems with large polygons being clipped away when they really shouldn't be... Using my (admittedly limited) mathbrain, I have deduced that the clipping problems arise when one or more of the transformed vertices have both z < 0 and w < 0. In those cases, the sign for z/w (normal 1/z) and z*w/w (linearz) are different: z/w > 0, whereas z*w/w < 0 In order to correct this, I changed the shader to use "vPos.z = vPos.z * abs(vPos.w)". Now, the signs match up again (z/w > 0 and z*abs(w)/w > 0) and the polygons are no longer clipped away. So far so good, but is this mathematically correct? Any chance of this hackery upsetting the clipper completely (thus accepting *all* polygons)? If anyone of you math wizzards could shed some light on this, that would be greatly appreciated! thx, Jim.  Jim Offerman Nixxes Software http://www.nixxes.com / http://www.jimofferman.nl 
From: Danny Kodicek <dragon@we...>  20051123 15:02:41

Hi: apologies that this is somewhat offtopic, if anyone would prefer to mail me offlist that would be fine. I've tried a few physicsrelated forums (and a couple of physics professors too), but haven't had much success, and I think people here may be more willing to be creative with it. The problem I'm working on is to calculate the magnetic field lines in an electric motor. I've got two bar magnets arranged poletopole and a wire loop between them. I'm considering it as a 2D problem only. I know how to calculate the field at any one point (which I'm doing by considering the magnets as a set of dipoles). (Quick physical explanation) A magnetic field line is a line of equipotential, which can be calculated by taking any point, moving a short distance in the direction of the field, and repeating until one has a loop (which should theoretically always happen, as there are no magnetic monopoles). The field lines are drawn a constant potential distance apart, which can be done by taking any curve in the space, integrating the normal component of field strength along the line, and drawing a line each time this reaches a constant multiple of some value. So here's my problem: If I take a point and draw the field line from that point, if the line gets too close to a currentcarrying wire it gets caught in the wire's field and starts to spiral in towards the centre, which is physically impossible. I've tried various methods for correcting for the error, from increasing the resolution of my field lines (no effect) to forcibly pushing the lines out of the way (the warping is obvious and I end up with lines getting crossed). I've also tried an alternative approach, which is to calculate the lines by using the integration method from a single reference line, or a line at infinity, but unfortunately while this removes the loops, it creates lines which are clearly heading in the wrong direction (sometimes even perpendicular to the field at some points). So can anyone suggest some method for correcting the problem? I'm not looking for the *correct* answer, just one that *looks* correct, so any algorithm that might tweak the existing answer would be interesting. My suspicion is that what I *really* need to do is fix the underlying error that makes the lines spiral in the first place. I'm thinking that the wires are acting kind of like a sink, and I need to add some field to them which will counteract this effect. But I'm not sure how I can measure the error to correct for it. Thanks for any insights Danny 