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
(4) 
2
(3) 
3
(3) 
4
(4) 
5
(10) 
6
(10) 
7
(6) 
8
(8) 
9
(1) 
10
(7) 
11
(7) 
12
(6) 
13
(6) 
14
(19) 
15
(1) 
16

17
(2) 
18
(3) 
19
(1) 
20

21
(2) 
22
(3) 
23
(2) 
24
(2) 
25

26
(3) 
27
(26) 
28
(4) 
29
(4) 
30







From: Robert Dibley <blimey.rob@go...>  20060403 23:34:40

How about taking the other view of this  instead of looking for the moving line segment which hits your point, look for the point on your line segment which will hit your point. So you are looking for t such that: (C  (A + t(BA))) cross (Av + t(BvAv)) = 0 ( Oh, I'm assuming you have already subtracted the velocity of C from everything, since that makes everything much easier ) So now you convert the above into a quadratic equation, find the solution(s) If they are <0 or >1 then they are outside the segment so ignore If not, then test for (Av + t(BvAv)) = 0 since this also gives the appearance of success when in fact it should fail. So long as that is not the case, then you are left with a known t which gives you a straight line which is known to pass through the point C, and so you can find the time of impact with a simple linear equation. You can probably do this last bit with a dot product too, since you don't need to do real collision at this point  you know it must pass through the point (barring fp inaccuracy) so just find : (C  (A + t(BA))) dot (Av + t(BvAv)) _____________________________ (Av + t(BvAv)) dot (Av + t(BvAv)) To give the fraction of time along the line that you need to travel. I'll leave the long winded expansion to quadratic for you to work out :) Regards Robert _____ From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of metanet software Sent: 02 April 2006 19:09 To: gdalgorithmslist@... Subject: Re: [Algorithms] Moving Segment vs Moving Point Intersection (2D) hi, just in case anyone else is going to use this  you actually can't naively discard the later intersection, because the quadratic gives you the intersection times of the _infinite_ line with the point. if you're interested in the segmentvspoint intersections (as i was), you have look at both roots to see if either represents an intersection with the lineseg; sometimes the earlier intersection is outside the lineseg, while the later one is in/on the lineseg. raigan Nils Pipenbrinck <n.pipenbrinck@...> wrote: Dave Moore wrote: > > Small niggle: you get a quadratic equation in t not a linear one, > right? There are cases where you get 2 crossings. Yes, but you're usually interested in the intersection that happends earliest. It's save to discard the greater one. Nils  This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.asus.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 _____ Share your photos with the people who matter at <http://photos.yahoo.ca>; Yahoo! Canada Photos 
From: david pangerl <david@zo...>  20060403 18:55:12

Why don't you divide this problem into two parts; A) simple quadrilaterals and B) selfintersecting/non simple quadrilateral or two triangles. Test for A or B should be simple (does AB intersect with A'B'; cross product vAAB and vBBA sign). You have a solution for A (line vs. quadrilaterals) and solution for B is even more simple (line vs. two triangles). I hope I didn't miss something. DAVID metanet software wrote: > hi, > thanks! > > Unfortunately, this won't work for me  it assumes that the quad > formed by A, B, A + vA*t,B + vB*t will be simple (i.e that the > diagonals will lie inside the area that the linseg sweeps out as it > moves). In the case where the segment spins in place, this breaks: A: > (0,1), B: (0,1), A+vA*t:(1,0), B+vB*t:(1,0) > > The lineseg sweeps out a shape that's a selfintersecting/nonsimple > quadrilateral, and the result will be a false positive if C is > (0.2,0.2) for instance. > > Since this test is being used for a "wire" simulation, this spinning > case can happen quite often. > > > My method doesn't give false positives, but does miss collisions if > the movement of the segment endpoints is large enough.. so it's > certainly not the most correct/robust method. > > > One approach which seems like it might work is a segmentvsquad test >  sadly I haven't figured out how to write that sort of test so that > it prope rly handles concave or selfintersecting quads.. and there's > nothing in good old "Geometric Tools.." ;) > > But I'm hoping that someone here has solved this already, it seems > like it should be fairly common  lots of games involve moving > segments and moving points.. > > raigan > > > */Greg Seegert <greg.seegert@...>/* wrote: > > If you consider your "moving point" as a line (C, C + vC * t), and > your "moving segment" as two triangles (A, B, A + vA * t and B, B + vB > * t, A + vA * t), that might simplify your tests a bit. A line > segment versus triangle intersection test is pretty well defined. > ________________________________________ > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On Behalf Of > metanet software > Sent: Saturday, March 11, 2006 4:51 PM > To: gdalgorithmslist@... > Subject: [Algorithms] Moving Segment vs Moving Point Intersection (2D) > > hi, > Hopefully someone can point me towards some good references/theory.. > movingsegment tests came up in the context of Carmageddon a while ago > (I think), but searching the archives hasn't turned anything up. > > My current "adhoc" algorithm is: > > given linesegment with endpoints A,B and endpoint velocities vA,vB, > and point C with velocity vC: > 1) find the velocity V of C relative to segment A>B** > 2) use this to perform a segmentvssegment test, using A>B vs > C>(C+V) > > **for step (1), I find the point on A>B closest to C, and use the > parametric description of this point to blend vA and vB together to > generate a single velocity for the segment (which is subtracted from > vC to get C's velocity from AB's frame of reference). > > Step 1 seems very approximate/hacky, since you can use any combination > of current or future positions, each of which will give you a > different result: > point on A>B closest to C > point on A>B closest to (C+vC) > point on (A+vA)>(B+vB) closest to C > point on (A+vA)>(B+vB) closest to (C+vC) > > ..there's no obvious "best"/most correct combination, which seems to > indicate that the "real" solution to this problem is probably not so > neat or linear, involving root finding or closestpointofapproach > calculation. > > Anyway, any tips, suggestions or references would be great, I'd really > like to know of any more accurate (or at least less > spontaneouslyinvented) approached. > > I should mention that I only need a boolean result, no time/point of > intersection. > > thanks, > raigan > ________________________________________ > Enrich your life at Yahoo! Canada Finance > > >  > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the > live webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.asus.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > >  > Make free worldwide PCtoPC calls. Try the new *Yahoo! Canada > Messenger with Voice* <http://ca.messenger.yahoo.com/>; > > > >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.1.375 / Virus Database: 268.2.1/279  Release Date: 3/10/2006 > > 
From: david pangerl <david@zo...>  20060403 18:50:00

Why don't you divide this problem into two parts; A) simple quadrilaterals and B) selfintersecting/non simple quadrilateral or two triangles. Test for A or B should be simple (does AB intersect with A'B'; cross product vAAB and vBBA sign). You have a solution for A (line vs. quadrilaterals) and solution for B is even more simple (line vs. two triangles). I hope I didn't miss something. DAVID metanet software wrote: > hi, > thanks! > > Unfortunately, this won't work for me  it assumes that the quad > formed by A, B, A + vA*t,B + vB*t will be simple (i.e that the > diagonals will lie inside the area that the linseg sweeps out as it > moves). In the case where the segment spins in place, this breaks: A: > (0,1), B: (0,1), A+vA*t:(1,0), B+vB*t:(1,0) > > The lineseg sweeps out a shape that's a selfintersecting/nonsimple > quadrilateral, and the result will be a false positive if C is > (0.2,0.2) for instance. > > Since this test is being used for a "wire" simulation, this spinning > case can happen quite often. > > > My method doesn't give false positives, but does miss collisions if > the movement of the segment endpoints is large enough.. so it's > certainly not the most correct/robust method. > > > One approach which seems like it might work is a segmentvsquad test >  sadly I haven't figured out how to write that sort of test so that > it prope rly handles concave or selfintersecting quads.. and there's > nothing in good old "Geometric Tools.." ;) > > But I'm hoping that someone here has solved this already, it seems > like it should be fairly common  lots of games involve moving > segments and moving points.. > > raigan > > > */Greg Seegert <greg.seegert@...>/* wrote: > > If you consider your "moving point" as a line (C, C + vC * t), and > your "moving segment" as two triangles (A, B, A + vA * t and B, B + vB > * t, A + vA * t), that might simplify your tests a bit. A line > segment versus triangle intersection test is pretty well defined. > ________________________________________ > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On Behalf Of > metanet software > Sent: Saturday, March 11, 2006 4:51 PM > To: gdalgorithmslist@... > Subject: [Algorithms] Moving Segment vs Moving Point Intersection (2D) > > hi, > Hopefully someone can point me towards some good references/theory.. > movingsegment tests came up in the context of Carmageddon a while ago > (I think), but searching the archives hasn't turned anything up. > > My current "adhoc" algorithm is: > > given linesegment with endpoints A,B and endpoint velocities vA,vB, > and point C with velocity vC: > 1) find the velocity V of C relative to segment A>B** > 2) use this to perform a segmentvssegment test, using A>B vs > C>(C+V) > > **for step (1), I find the point on A>B closest to C, and use the > parametric description of this point to blend vA and vB together to > generate a single velocity for the segment (which is subtracted from > vC to get C's velocity from AB's frame of reference). > > Step 1 seems very approximate/hacky, since you can use any combination > of current or future positions, each of which will give you a > different result: > point on A>B closest to C > point on A>B closest to (C+vC) > point on (A+vA)>(B+vB) closest to C > point on (A+vA)>(B+vB) closest to (C+vC) > > ..there's no obvious "best"/most correct combination, which seems to > indicate that the "real" solution to this problem is probably not so > neat or linear, involving root finding or closestpointofapproach > calculation. > > Anyway, any tips, suggestions or references would be great, I'd really > like to know of any more accurate (or at least less > spontaneouslyinvented) approached. > > I should mention that I only need a boolean result, no time/point of > intersection. > > thanks, > raigan > ________________________________________ > Enrich your life at Yahoo! Canada Finance > > >  > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the > live webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.asus.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > >  > Make free worldwide PCtoPC calls. Try the new *Yahoo! Canada > Messenger with Voice* <http://ca.messenger.yahoo.com/>; > > > >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.1.375 / Virus Database: 268.2.1/279  Release Date: 3/10/2006 > > 