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
(5) 
2
(9) 
3
(1) 
4
(2) 
5

6
(3) 
7

8

9

10
(1) 
11
(3) 
12

13
(4) 
14

15

16
(2) 
17
(7) 
18
(3) 
19
(5) 
20
(1) 
21

22

23

24
(1) 
25
(7) 
26
(9) 
27
(3) 
28

29
(1) 
30
(10) 
31
(5) 




From: <pierloic@fr...>  20050531 15:50:03

Thanks for your contributions. I think i did progress a bit since the initial post as i managed to list = two main pathological cases and i *feel* like i have a solution for the first= one :). I still cant find anything for the second case and that is the bad news..= . I did a page to explain where i am, you might have a look if you whish : http://pierloic.free.fr/clip/clip.html I dont have precision problems for the moment. I simply use fabs(ab)<eps= ilon. That's allright for now and i dont get equality test problems. It may bec= ome an issue later... I do some strong states check with asserts. Mainly on even count of intersections and the alternates but that is after the graph is built. So: 1) If anyone can think of something about those cases, that's *cool* !!! 2) Reading your posts, it sounds like i should give up with this... Is there any other algorithm for the same specifications:  concave with holes polygon clipped with concave with holes polygon  the algorithm outputs 2 lists: inside polygons and outside polygons  ability to use results as inputs for several passes Thanks  Pierre Loic 
From: Gino van den Bergen <gvandenbergen@pl...>  20050531 10:03:42

=20 > Original Message > From: gdalgorithmslistadmin@...=20 > [mailto:gdalgorithmslistadmin@...] On=20 > Behalf Of Bretton Wade > Sent: Tuesday, May 31, 2005 10:45 AM > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Weiler Atherton Implementation (2D=20 > polygon clipping) >=20 <snip> >=20 > 1) Be careful about testing for equality. This comes up in=20 > the collocation and collinear testing a lot. Epsilon testing=20 > is a generally accepted method for comparison of floats=20 > [abs(ab)<epsilon], but breaks down if epsilon is meaningless=20 > in the range of numbers you are working in. A better test is=20 > looking for least significant bits of deviation (typecast the=20 > floats to ints, and compare the result to less than some=20 > small enough integer tolerance). >=20 I would like to add that you should try to relate your epsilon to the actual input data. For instance, my (hyper)plane object maintains a noise value that is used to determine whether a point lies on the plane. Given a normal, an offset, and a noise value, a point p lies on the plane if dot(normal, p)  offset <=3D noise. The noise value is not an absolute epsilon. Rather, it is computed from the vertices that are known to lie on the plane. Computed normals are usually not perfectly orthogonal to the support plane of a polygon. Therefore, for these vertices, the signed distance dot(normal, p)  offset will not be exactly zero. The noise value is the maximum absolute signed distance of a vertex that is known to lie on the plane. Furthermore, I add an epsilon to this noise value that is related to the offset in order to catch rounding errors. This espilon is taken to be offset * std::numeric_limits<float>::epsilon() * C, where C is a small positive constant (e.g. 10). In this way, planes that are further away from the origin will have a larger noise value. You should be careful comparing floats by casting them to integers. You would like the float values 1.0 * 2^exp and 1.11111111111111111111111 * 2^(exp1) (in base2 representation) to be classified as equal. However, a direct cast to integer (through *reinterpret_cast<int*>(&value)) will show different values after masking away the least significant bits. It is better to get rid of the N least significant bits by adding a bias value that is 1.0 * 2^(exp + N) (2^N times the absolute maximum of the two) to both values and compare their 32bit float values. For N =3D 8, adding the bias results in 1.00000001000000000000000 * 2^(exp + N) for both values after rounding. (In order to make sure that you're testing only 32 bits and not the 80bit internal representation you could cast them to integers using the pointer cast, or use the floatconsistency compiler option Op.)=20 Gino 
From: Willem de Boer <wdeboer@pl...>  20050531 09:34:59

I recently had to implement a polygon scene clipper algorithm. I used a beamtree to speed up poly clipping, and a BSP tree to feed the beamtree a fronttoback ordered list of polygons. My findings were that you _do not_ want to convert to triangles during your beamtree and BSP tree constructions, as this will i) result in an exponential increase of tree nodes and ii) will entice a lot of roundingerror creepiness. Bretton Wade wrote: "As a general rule, clipping algorithms on complex=20 geometry are not robust and accurate with floating=20 point math. " I can also confirm this. Cheers, Willem 
From: Bretton Wade <brettonw@mi...>  20050531 08:45:12

(Despite my experience in this area, I continue to believe that object space algorithms like this can be made to work. It's my masochistic tendencies showing through.) As a general rule, clipping algorithms on complex geometry are not robust and accurate with floating point math.=20 In any large enough data set, you will find at least one unexpected special case that you must solve. The last two assertions you claim to have trouble with (types of intersections will alternate and the number will always be even) are implications of the Jordan curve theorem (Any continuous simple closed curve in the plane separates the plane into two disjoint regions: the inside and the outside.) You have to make these work in order to be sure the clipper is correct. If this is for offline processing, use arbitrary precision arithmetic to eliminate a major source of accuracy errors. It will be slow, but the alternative is manually examining thousands of failure cases. BSP based clipping is no better than the WeilerAtherton algorithm in the long run; it's just easier to code the operations. Unfortunately it will also give you more polygons, meaning more opportunities for error. I implemented the Sutherland and Hodgman algorithm a few years back for offline processing of water polygons in Flight Simulator. Polys with holes were clipped only to quads, and I had a @$%$ of a time getting that robust across the entire world.=20 Here are a few suggestions: 1) Be careful about testing for equality. This comes up in the collocation and collinear testing a lot. Epsilon testing is a generally accepted method for comparison of floats [abs(ab)<epsilon], but breaks down if epsilon is meaningless in the range of numbers you are working in. A better test is looking for least significant bits of deviation (typecast the floats to ints, and compare the result to less than some small enough integer tolerance). 2) Error check your input religiously. You want polygon chains that are simple, have no collinear or collocated vertices, have area greater than 0, etc., etc. Do all this conditioning before you feed the clipper, not while you feed it. Punt on any polygon that isn't well conditioned. 3) Skip the alternative winding order hole polygon approach if you can. I inserted the hole polygon into the source polygons and updated the test for simpleness to allow collinear edges in the polygon. This removes one major source of complexity from the algorithm. 4) Isolate your intersection routines so that they always order line segments the same way. This ensures that you get the same intersection point whether you are considering AB intersects CD, or CD intersects AB (or DC intersects BA...) 5) To make the Jordan curve theorem hold, I found that I had to sort the intersections along the clipping plane and fudge it if I got multiple intersection points that appeared to be collocated. Basically the sort routine had to enforce the alternating nature of the intersection points. If you keep going down this road... Good luck and please report back on your results. Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Andrew Willmott Sent: Monday, May 30, 2005 12:51 PM To: gdalgorithmslist@... Subject: Re: [Algorithms] Weiler Atherton Implementation (2D polygon clipping) The short version: WA is not a practical, robust algorithm. This is not=20 a problem you can solve. The long version: a friend of mine was working on 2D clipping algorithms for his Master's thesis. He ran into exactly the same problems you=20 describe, and spent a lot of time trying to fix them. He eventually got=20 in touch with one of the paper authors, and established that their code=20 had the same set of problems. It was a nice algorithm in theory, but it=20 inevitably ran into robustness issues in practice. He went on to write=20 his own, which was based off a BSP tree approach, I think. (I might be=20 wrong about that  this was all over ten years ago, and I can't find=20 his thesis online. It was "Objectprecision methods for visible surface=20 determination", J. Williams, University of Auckland..) Andrew pierloic@... wrote: >Hello, > >I am implementing the Weiler Atherton algorithm as it really matches my needs >for some physic dev: > concave with holes polygon clipped with concave with holes polygon > the algorithm outputs 2 lists: inside polygons and outside polygons > ability to use results as inputs for several passes > >You can find the original article here : >http://www.cs.drexel.edu/~david/Classes/CS430/HWs/p214weiler.pdf > > >The general cases works really good but it is getting harder with the >pathological cases when some intersections points happens to be the same as >some polygon points: > 2 non parallel edges intersect on one end of one edge > 2 non parallel edges intersect on one end of one edge which is also an end of >the other edge > 2 parallel edges intersect on two points which are end of edges > >I tried different ways to treat them (insert intersection nodes or not) but >nothing really works for the moment. > >The paper is quite "vague" about it : >"If care is taken in placement of intersections where the subject and clip >polygon contours are identical in the xy plane, no degenerate polygons will be >produced by the clipping process" > >Then the text makes two assertions : >"These two types of intersections will be found to alternate along any given >contour and the number of intersections will always be even" > >I cant satisfy these two assertions with the different approaches i tried for >the pathological cases... > >Anyone has experimented these issues ? Any help is welcome. > >Thanks, > >Pierre Loic Herve > > > >SF.Net email is sponsored by: GoToMeeting  the easiest way to collaborate >online with coworkers and clients while avoiding the high cost of travel and >communications. There is no equipment to buy and you can meet as often as >you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id=16135&op=3Dclick >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > =20 >  This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network  Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications  visit http://developer.yahoo.net/?fr=3Doffadysdnostgq22005 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Willem de Boer <wdeboer@pl...>  20050531 06:56:46

Really, it should happen in texture space, as that's the closest you will get to integrating in the tangent plane. Ofcourse, this won't work where there are texture discontinuities. In fact, it would only really be correct if the mesh can be nicely unfolded onto the sphere. The best results I got when I compute an irradiance map from the lightsource (a la Dachsbacher et al.) and use that=20 information to integrate against, as well as filtering in=20 image space. That way, you get light shining through thin=20 parts of the mesh. (You can also use this depth map to=20 compute the single scattering term, ofcourse).  Willem H. de Boer Homepage: http://www.whdeboer.com=20 > Original Message > From: gdalgorithmslistadmin@...=20 > [mailto:gdalgorithmslistadmin@...] On=20 > Behalf Of Rowan Wyborn > Sent: Tuesday, May 31, 2005 1:27 AM > To: gdalgorithmslist@... > Subject: RE: [Algorithms] Subsurface scattering >=20 > cool! Its nice to finally see an analytical derivation for=20 > such a hacky 'just works' algorithm :) >=20 > One thing that wasnt clear to me was whether the application=20 > of the kernel was happening in texture space (ala traditional=20 > subsurface 'blur' approximation) or in image space or??? >=20 > > Original Message > > From: Willem de Boer [mailto:wdeboer@...] > > Sent: Friday, 27 May 2005 4:44 PM > > To: gdalgorithmslist@... > > Subject: [Algorithms] Subsurface scattering > >=20 > >=20 > > Hi all. > >=20 > > I've put up a draft of an article that describes how to simulate=20 > > sufficiently local multiplescattering (ie.,=20 > semitranslucent objects)=20 > > effects in realtime. Under some simplifying assumptions I show how=20 > > the full BSSRDF integral can be put into a much simpler=20 > form that is=20 > > simple enough to be evaluated quickly enough. > >=20 > > The paper can be found here: > > http://www.whdeboer.com/writings.html > >=20 > > Remember, it's a draft. There's bits missing, but the gist of the=20 > > technique is there. The justification for the paper is that=20 > a lot of=20 > > people simulate multiple scattering by blurring. This paper=20 > shows that=20 > > blurring actually has theoretical grounding. > >=20 > > Some screenshots can be found here: > > http://www.whdeboer.com/misc.html > >=20 > > I hope you like it. Enjoy! > >=20 > > Cheers, > > Willem > >=20 > >=20 > >=20 > >=20 > >  > > This SF.Net email is sponsored by Yahoo. > > Introducing Yahoo! Search Developer Network  Create apps=20 > using Yahoo! > > Search APIs Find out how you can build Yahoo! directly into=20 > your own=20 > > Applications  visit > > http://developer.yahoo.net/?fr=3Dfadysdnostgq22005 > > _______________________________________________ > > 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 Yahoo. > Introducing Yahoo! Search Developer Network  Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into=20 > your own Applications  visit=20 > http://developer.yahoo.net/?fr=3Dfadysdnostgq22005 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 