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
(44) 
2
(37) 
3
(50) 
4
(5) 
5
(7) 
6
(14) 
7
(34) 
8
(18) 
9
(43) 
10
(75) 
11
(7) 
12
(3) 
13
(43) 
14
(19) 
15
(29) 
16
(21) 
17
(54) 
18
(12) 
19

20
(36) 
21
(9) 
22
(18) 
23
(30) 
24
(29) 
25
(18) 
26
(18) 
27
(38) 
28
(23) 
29
(21) 
30
(11) 
31
(19) 

From: Douglas Cox <ziflin@ho...>  20010825 23:46:00

>Excuse me for asking, but don't you WANT it to be thrown off. I am assuming >you are using this for a game and if I was playing you game and the >targeting was exactly correct for every case I would get extremely >frustrated.. unless you are using this for autoaiming :) This is for autoaiming in a 3rd person view as well as for AI, so it needs to be pretty accurate when we want it to be. Ye, it would be annoying to get hit every time, but the closer I can get to that, the closer we can let stats or skill levels factor into how many times the player actually gets hit. also >I think you can recalculate intersection point for every tick, so when >target change velocity vector or acceleration, >you recalc new intersection point and adjust direction of projectile >accordinally, this would look more or less like homing missle. I do this for our homing missiles and it seems to work very well. For laser shots, I don't think it would look great unless I constrain the angle at which it 'cheats' to something fairly small. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp 
From: Arvid <arvid@in...>  20010825 23:43:31

Hello, Maybe you should have a look at Paul Bourke's "Polygonising a Scalar Field Using Tetrahedrons". I don't know if there are any patents. http://astronomy.swin.edu.au/pbourke/modelling/polytetra/index.html  Arvid Norberg  Original Message  From: "Jeremy Bake" <Jeremy.Bake@...> To: <gdalgorithmslist@...> Sent: Friday, August 24, 2001 5:31 PM Subject: [Algorithms] marching cubes alternative > what other volume surface reconstruction algorithms are there? > I was just getting excited about Marching Cubes when I caught > reference to the patent GE holds on it... > > anyone know of any good alternative to get basically the > same results (you know, that I'd be able to use and all) > > thnx a bunch > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > 
From: Pierre Barthe <Serge.Bakkal@PBASoft.com>  20010825 23:17:35

and if someone has a problem with it, you = anal Man , the search engine returns no result on AI search ? Serge 
From: Pierre Barthe <pbarthe@PBASoft.com>  20010825 22:38:13

Oops , forgive Outlook for this double post 
From: akbara <syedali011@ea...>  20010825 22:29:00

it's been discussed before, feel free to discuss it again. i like reading about ai+pathfinding problems ;) you might wnat to check out the archives first though... some good stuff.. and if someone has a problem with it, you = anal akbar A. On Sat, 25 Aug 2001 23:39:55 +0200 "Serge Bakkal" <Serge.Bakkal@...> wrote: > Hi , > It seems that AI is not a current topic on this list , > is there a better place to have AI related things discussed > (not only pathfinding is the concern , but hierarchical AI > is sensible here ) > > Serge > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist  "it's called Mario Twins, and I WANT TO PLAY IT" http://vertexabuse.cjb.net 
From: Serge Bakkal <Serge.Bakkal@PBASoft.com>  20010825 21:41:23

Hi , It seems that AI is not a current topic on this list , is there a better place to have AI related things discussed (not only pathfinding is the concern , but hierarchical AI is sensible here ) Serge 
From: Christopher Husband <chusband@ca...>  20010825 18:38:21

Idahosa, I have written an RKF ODE solver before and might be able to help with specific questions if you have any. If you have access to Matlab, it might be of some assistence to attempt you're algorithm there first, so that the matrix and vector math is taken care of. Plus Matlab has plenty of 'ode??' functions that you can compare yours to. Chris On Sat, 25 Aug 2001, Idahosa Edokpayi wrote: > I understand the basic idea of Runge Kutta solvers but my attempts to > implement them have failed miserably. Can anyone help? > > Idahosa Edokpayi > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > 
From: Charles Bloom <cbloom@cb...>  20010825 18:29:55

See the "Numerical Recipes" book. At 01:02 PM 8/25/2001 0500, you wrote: >I understand the basic idea of Runge Kutta solvers but my attempts to >implement them have failed miserably. Can anyone help?  Charles Bloom cb@... http://www.cbloom.com 
From: Idahosa Edokpayi <idahosae@sw...>  20010825 18:03:05

I understand the basic idea of Runge Kutta solvers but my attempts to implement them have failed miserably. Can anyone help? Idahosa Edokpayi 
From: Idahosa Edokpayi <idahosae@sw...>  20010825 14:23:47

I understand but depending on the physical constraints the number of cases could be small. Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Keith Harrison Sent: Saturday, August 25, 2001 5:10 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] Target leading  Original Message  From: "Idahosa Edokpayi" <idahosae@...> To: <gdalgorithmslist@...> Sent: Saturday, August 25, 2001 4:33 AM Subject: RE: [Algorithms] Target leading > Excuse me for asking, but don't you WANT it to be thrown off. I am assuming > you are using this for a game and if I was playing you game and the > targeting was exactly correct for every case I would get extremely > frustrated.. unless you are using this for autoaiming :) Bear in mind that you can calculate *exactly* where an object is going to be in x seconds, but getting there is not always possible (unless you ignore physical constraints). Regards, Keith Harrison. _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: Gribb, Gil <ggribb@ra...>  20010825 14:07:00

> Can anyone explain, or point me to somewhere, that does a > moving sphere > versus a static triangle? Here is a moving triangle vs unit sphere at the origin test, that I designed and implemented. It handles your case (and ellipsoids). You have to subtract the initial sphere origin from the triangle verts. Then scale all components of the triangle verts and the movement vector (called the velocity in the code) by the inverse of the sphere radius. Finally, negate the movement vector, since we are considering the triangle moving not the sphere. Without further ado, the code. ( ^ is a dot product). Gil bool SegmentUnitSphereAtOriginTest(const CVect3 &start,const CVect3 &end,CVect3 *returnedPoint,float *returnedT) { // a quick box test if (start.x()<1.0f&&end.x()<1.0f) { return false; } if (start.x()>1.0f&&end.x()>1.0f) { return false; } if (start.y()<1.0f&&end.y()<1.0f) { return false; } if (start.y()>1.0f&&end.y()>1.0f) { return false; } if (start.z()<1.0f&&end.z()<1.0f) { return false; } if (start.z()>1.0f&&end.z()>1.0f) { return false; } // compute dir, a unit vector in the direction if the segment CVect3 dir=end; dir=start; float invLen=1.0f/dir.Len(); dir*=invLen; // compute minimum distance to collision, d float dot=start^dir; float det=1.0f+dot*dot(start^start); if (det<0.0f) { return false; // segment misses sphere } float d=((dir^start)+sqrt(det)); if (d<0.0f) { return false; // segment is either start solid or misses } float t=d*invLen; // convert back to 01 t param if (t>1.0f) { return false; // collides after the end of the segment } if (returnedT) { *returnedT=t; } if (returnedPoint) { *returnedPoint=dir; (*returnedPoint)*=d; (*returnedPoint)+=start; assert(fabs(returnedPoint>Len2()1.0f)<0.1f); } return true; } bool UnitSphereAtOriginTriangleTest( const CVect3 &velocity, //for the triangle const CVect3 &A,const CVect3 &B,const CVect3 &C, //triangle bool backFaces,bool frontFaces, // which faces to accept CVect3 &returnedPoint,CVect3 &returnedNormal,float &returnedT) { static const float tiny=1E10f; returnedT=1.01f; // start off the end CVect3 edgeAC=C; edgeAC=A; CVect3 edgeAB=B; edgeAB=A; returnedNormal=edgeAB; returnedNormal.Cross(edgeAC); float denom=velocity^returnedNormal; if ( (!backFaces&&denom>0) // not accepting back faces (!frontFaces&&denom<0)) //not accepting front faces { return false; } bool doFace=fabs(denom)>tiny; CVect3 Av=A; Av+=velocity; CVect3 Bv=B; Bv+=velocity; CVect3 Cv=C; Cv+=velocity; // test the 3 verts CVect3 retp; float rett; if (SegmentUnitSphereAtOriginTest(A,Av,&retp,&rett)) { if (rett<returnedT) { returnedT=rett; returnedPoint=retp; } } if (SegmentUnitSphereAtOriginTest(B,Bv,&retp,&rett)) { if (rett<returnedT) { returnedT=rett; returnedPoint=retp; } } if (SegmentUnitSphereAtOriginTest(C,Cv,&retp,&rett)) { if (rett<returnedT) { returnedT=rett; returnedPoint=retp; } } // now test the three edges CVect3 start,end; float ts,te; float invLenAC=1.0f/edgeAC.Len(); edgeAC*=invLenAC; ts=(A^edgeAC); te=(Av^edgeAC); if ( (ts>0.0fte>0.0f)&& // the line of impact is off this edge (ts*invLenAC<1.0fte*invLenAC<1.0f)) // the line of impact is off this edge { start=edgeAC; start*=ts; start+=A; end=edgeAC; end*=te; end+=Av; if (SegmentUnitSphereAtOriginTest(start,end,&retp,&rett)) { if (rett<returnedT) { float test=((tets)*rett+ts)*invLenAC; if (test>0.0f&&test<1.0f) { returnedT=rett; returnedPoint=retp; } } } } float invLenAB=1.0f/edgeAB.Len(); edgeAB*=invLenAB; ts=(A^edgeAB); te=(Av^edgeAB); if ( (ts>0.0fte>0.0f)&& // the line of impact is off this edge (ts*invLenAB<1.0fte*invLenAB<1.0f)) // the line of impact is off this edge { start=edgeAB; start*=ts; start+=A; end=edgeAB; end*=te; end+=Av; if (SegmentUnitSphereAtOriginTest(start,end,&retp,&rett)) { if (rett<returnedT) { float test=((tets)*rett+ts)*invLenAB; if (test>0.0f&&test<1.0f) { returnedT=rett; returnedPoint=retp; } } } } CVect3 edgeCB=B; edgeCB=C; float invLenCB=1.0f/edgeCB.Len(); edgeCB*=invLenCB; ts=(C^edgeCB); te=(Cv^edgeCB); if ( (ts>0.0fte>0.0f)&& // the line of impact is off this edge (ts*invLenCB<1.0fte*invLenCB<1.0f)) // the line of impact is off this edge { start=edgeCB; start*=ts; start+=C; end=edgeCB; end*=te; end+=Cv; if (SegmentUnitSphereAtOriginTest(start,end,&retp,&rett)) { if (rett<returnedT) { float test=((tets)*rett+ts)*invLenCB; if (test>0.0f&&test<1.0f) { returnedT=rett; returnedPoint=retp; } } } } // and finally the surface of the triangle if (doFace) { CVect3 perpCB=edgeCB; perpCB.Cross(returnedNormal); float invLenPerpCB=1.0f/perpCB.Len(); perpCB*=invLenPerpCB; start=edgeCB; start*=(C^edgeCB); CVect3 temp=perpCB; temp*=(C^perpCB); start+=temp; start+=C; end=edgeCB; end*=(Cv^edgeCB); temp=perpCB; temp*=(Cv^perpCB); end+=temp; end+=Cv; if (SegmentUnitSphereAtOriginTest(start,end,&retp,&rett)) { if (rett<returnedT) { // set At Bt Ct to the triangle at the time of contact CVect3 At=velocity; At*=rett; CVect3 Bt=At; CVect3 Ct=At; At+=A; Bt+=B; Ct+=C; CVect3 edgePA=At; edgePA=retp; CVect3 edgePB=Bt; edgePB=retp; CVect3 edgePC=Ct; edgePC=retp; // now see if the hit spot is in the triangle temp=edgePA; temp.Cross(edgePB); if ((temp^returnedNormal)>=0.0f) { temp=edgePC; temp.Cross(edgePA); if ((temp^returnedNormal)>=0.0f) { temp=edgePB; temp.Cross(edgePC); if ((temp^returnedNormal)>=0.0f) { returnedT=rett; returnedPoint=retp; } } } } } } if (returnedT<=1.0f) { returnedNormal*=1.0f; CVect3 tvel=velocity; tvel*=returnedT; returnedPoint+=tvel; return true; } return false; } 
From: Timur Davidenko <timur@cr...>  20010825 11:08:25

I think you can recalculate intersection point for every tick, so when target change velocity vector or acceleration, you recalc new intersection point and adjust direction of projectile accordinally, this would look more or less like homing missle. regards.  Timur Davidenko timur@...  Original Message  From: "Douglas Cox" <ziflin@...> To: <gdalgorithmslist@...> Sent: Friday, August 24, 2001 11:23 PM Subject: [Algorithms] Target leading > Given a target moving with a constant (linear) velocity and an object firing > a projectile with a constant speed, I've managed to calculate the > intersection point. However a target with a constant angular velocity (say > flying in a tight circle) throws the leading off completely. > > So, can anyone suggest better methods for performing target > leading/prediction? I know there is plenty of research on this, but most of > what I found on google/etc looked a little excessive  or maybe that's just > from my lack of understanding it all. > > Thanks, > doug > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > 
From: Keith Harrison <Keithhar@bt...>  20010825 10:42:57

 Original Message  From: "Idahosa Edokpayi" <idahosae@...> To: <gdalgorithmslist@...> Sent: Saturday, August 25, 2001 4:33 AM Subject: RE: [Algorithms] Target leading > Excuse me for asking, but don't you WANT it to be thrown off. I am assuming > you are using this for a game and if I was playing you game and the > targeting was exactly correct for every case I would get extremely > frustrated.. unless you are using this for autoaiming :) Bear in mind that you can calculate *exactly* where an object is going to be in x seconds, but getting there is not always possible (unless you ignore physical constraints). Regards, Keith Harrison. 
From: Idahosa Edokpayi <idahosae@sw...>  20010825 03:34:16

Excuse me for asking, but don't you WANT it to be thrown off. I am assuming you are using this for a game and if I was playing you game and the targeting was exactly correct for every case I would get extremely frustrated.. unless you are using this for autoaiming :) Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Douglas Cox Sent: Friday, August 24, 2001 4:23 PM To: gdalgorithmslist@... Subject: [Algorithms] Target leading Given a target moving with a constant (linear) velocity and an object firing a projectile with a constant speed, I've managed to calculate the intersection point. However a target with a constant angular velocity (say flying in a tight circle) throws the leading off completely. So, can anyone suggest better methods for performing target leading/prediction? I know there is plenty of research on this, but most of what I found on google/etc looked a little excessive  or maybe that's just from my lack of understanding it all. Thanks, doug _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: Pop N Fresh <pop_n_fresh@te...>  20010825 03:26:40

Magic Software has what you're looking for. http://www.magicsoftware.com/Source/Distance3D/MgcDist3DLinTri.cpp Use the code to find the distance between a segment and a triangle. If the distance is smaller than the radius of your sphere they collide. kelvi  Original Message  From: "Michael Hughes" <mhughes@...> To: <gdalgorithmslist@...> Sent: Friday, August 24, 2001 17:36 Subject: Re: [Algorithms] Moving sphere, moving triangle collision > Can anyone explain, or point me to somewhere, that does a moving sphere > versus a static triangle? > I've checked out most of the obvious references (Graphic Gems, Game Gems, > Magic Software) and I still haven't come across an example, or paper, which > has moving sphere versus triangle collision detection. I can detect > collision between a plane and a moving sphere, but detecting whether or not > a triangle collides with a triangle is trickier. What's got me stuck is the > collision with the edges of the triangle. I can determine that the point of > contact between the sphere and the triangle isn't within the triangle, but I > can't figure out how to determine point along the sphere's path that it > intersects with an edge, if it does at all. There's lots of stuff I've read > which tells how to do a ray/line segment test, but this doesn't help me, as > my sphere is moving and I can't see away to apply a moving sphere to those > equations. And most of the code I've come across (gamasutra article and > others) do collision between the triangle and a moving sphere, but don't > handle edge collisions. > Can anyone help? > > Thanks, > Mike > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > 
From: Charles Bloom <cbloom@cb...>  20010825 01:40:20

This was in game developer magazine two months ago. At 05:36 PM 8/24/2001 0700, you wrote: >Can anyone explain, or point me to somewhere, that does a moving sphere >versus a static triangle? >I've checked out most of the obvious references (Graphic Gems, Game Gems, >Magic Software) and I still haven't come across an example, or paper, which >has moving sphere versus triangle collision detection. I can detect >collision between a plane and a moving sphere, but detecting whether or not >a triangle collides with a triangle is trickier. What's got me stuck is the >collision with the edges of the triangle. I can determine that the point of >contact between the sphere and the triangle isn't within the triangle, but I >can't figure out how to determine point along the sphere's path that it >intersects with an edge, if it does at all. There's lots of stuff I've read >which tells how to do a ray/line segment test, but this doesn't help me, as >my sphere is moving and I can't see away to apply a moving sphere to those >equations. And most of the code I've come across (gamasutra article and >others) do collision between the triangle and a moving sphere, but don't >handle edge collisions. >Can anyone help? > >Thanks, >Mike > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist  Charles Bloom cbloom@... http://www.cbloom.com 
From: Andy Ross <andy@ne...>  20010825 01:14:55

Chris Hecker wrote: > Jon Watte wrote: > >The fully correct solution is to multiply by the transpose inverse of the > >skinning matrix. > > Actually, this is not correct. Actually, it's sort of correct. What he said is true for the normal of a PLANE. The problem, of course, is that the "normal of a vertex" is a poorly defined thing that is arrived at via some kind of heuristic averaging of the normals of the associated triangles. This averaging operation isn't a matrix, and doesn't commute with the inverse transpose operation. I'm sure you know that. I just thought it would be useful to point out why the answer was wrong in a way that gelled with the "normals transform by the inverse transpose" rule (which is a really important thing to grok, IMHO). Andy  Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA andy@... http://www.nextbus.com (510)4203126 Why Wait? 
From: Michael Hughes <mhughes@h2...>  20010825 00:39:53

Can anyone explain, or point me to somewhere, that does a moving sphere versus a static triangle? I've checked out most of the obvious references (Graphic Gems, Game Gems, Magic Software) and I still haven't come across an example, or paper, which has moving sphere versus triangle collision detection. I can detect collision between a plane and a moving sphere, but detecting whether or not a triangle collides with a triangle is trickier. What's got me stuck is the collision with the edges of the triangle. I can determine that the point of contact between the sphere and the triangle isn't within the triangle, but I can't figure out how to determine point along the sphere's path that it intersects with an edge, if it does at all. There's lots of stuff I've read which tells how to do a ray/line segment test, but this doesn't help me, as my sphere is moving and I can't see away to apply a moving sphere to those equations. And most of the code I've come across (gamasutra article and others) do collision between the triangle and a moving sphere, but don't handle edge collisions. Can anyone help? Thanks, Mike 