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
(12) 
2
(6) 
3
(5) 
4
(5) 
5
(11) 
6
(3) 
7
(2) 
8
(11) 
9
(35) 
10
(38) 
11
(41) 
12
(18) 
13
(11) 
14
(16) 
15
(7) 
16
(31) 
17
(18) 
18
(5) 
19
(1) 
20

21
(20) 
22
(15) 
23
(33) 
24
(18) 
25
(46) 
26
(19) 
27
(2) 
28
(33) 
29
(31) 
30
(29) 
31
(24) 


From: Bob Dowland <Bob.Dowland@bl...>  20030718 15:13:43

> 5) 12 axes that are orthogonal to each edge of box and=20 > cylinder's top circle edge > 6) 12 axes that are orthogonal to each edge of box and=20 > cylinder's bottom circle edge Alen, As usual very interesting to hear your angle on this!=20 24 seems like such a large number! I have to admit I would have probably = stopped after the first seven in your list :) So are you picking the normal to each circle at the point (on the = circle) that is closest to that edge? =09 ie. p =3D circlePointClosest(edge, circle) n =3D grad(circle(p)) testaxis =3D cross(n, edge) Bob. > Original Message > From: Alen Ladavac [mailto:alengdalgs@...] > Sent: 18 July 2003 09:05 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] seperating axes with cylinders >=20 >=20 > Generally, when we were designing our separatingaxis=20 > colliders, we were following this idea: You > need one separating axis for each possible pair of closest=20 > features (all combinations of > vertexvertex, vertexface, etc). Canonically, for boxbox,=20 > each box has 6 faces, 12 edges and 8 > vertices, it would give you (6+12+8)^2=3D676 combinations. In=20 > most cases, a lot of combinations are > usually represented by the same axis. E.g, one axis of box A=20 > handles separation of its two faces > against all other features on box B. That's why the boxbox=20 > collider ends up with only 15 axis. >=20 > For cylinderbox, there are 6 box faces, 12 box edges, 8 box=20 > vertices, 2 cylinder flat surfaces (top > and bottom), 1 cylinder shell (is this the right word for the=20 > curved surface on the cylinder?) and 2 > cylinder's circle edges (the sharp helix along the end of the=20 > cylinder shell). > That would give (6+12+8)*(2+1+2)=3D130 axes. Unfortunately,=20 > these don't merge as easily as boxbox, so > we actually have 39 (!) axes. The 24 axes I mentioned in the=20 > post you refer to, are just that last > 24 (2x12) "box edge vs. cylinder circle edge" axes that bothered me. >=20 > Here's the whole set: > 1) 3 box axes  they handle box faces against all cylinder features, > 2) 1 cylinder axis  handles the top and bottom ends of the=20 > cylinder against all box features, > 3) 3 cross products of cylinder axis with box axes  they=20 > handle cylinder shell against box edges > 4) 8 axis through the box vertices orthogonal to cylinder=20 > axis  handle vertices against the > cylinder shell > 5) 12 axes that are orthogonal to each edge of box and=20 > cylinder's top circle edge > 6) 12 axes that are orthogonal to each edge of box and=20 > cylinder's bottom circle edge >=20 > This uses only projection onto axes, and there is no=20 > numerical root finding involved  the solution > is completely analytical. >=20 > The axes in 5) and 6) are a bit more complicated to derive=20 > than the others, but not nearly as hard > to understand as the rootfinding methods proposed in the=20 > paper from MagicSoftware website (all > praises to Mr. Eberly, as I honor his work a lot, but some=20 > parts are just too complicated for > something I'd have in my collider's inner loop :)). All other=20 > axes are simple and straight forward. >=20 > I don't claim to have a mathematical proof of the correctness=20 > of the method, or to say that it is > faster than numerical methods. But it certainly works for us=20 > so far, it is _very_ simple to > implement, works in constant bounded time, and offers a lot=20 > of earlyouts. >=20 > Also, there is a great potential in quickly discarding most=20 > of the axes in 4), 5) and 6). I believe > that only 1 out of 8 in 4), and 1 out of 24 in 5) and 6) are=20 > relevant. But it will need to wait > until this starts choking on some more complex scenes, so we=20 > are forced to devote time to optimizing > it. :) >=20 > If anyone finds a problem with this, or sees some=20 > optimization, please do let me know. I plan to > make a document explaining all the colliders we use (sphere,=20 > box, capsule, cylinder, mesh), together > with the actual contact point and penetration depth=20 > computations. I'd like to have that public so > that it can be verified, and also to help putting an end to=20 > this neverending secrecy around simple > and robust collision detection methods. Unfortunately, I=20 > don't have that much spare time right now, > so I'll just resort to short (?) discussions like this. >=20 > Alen >=20 >=20 >=20 >  Original Message  > From: metanet metanet > To: gdalgorithmslist@... > Sent: Thursday, July 17, 2003 7:00 PM > Subject: [Algorithms] seperating axes with cylinders >=20 >=20 > hi, > i'm currently trying to find all seperating axes that need to=20 > be checked for boxcylinder > intersection. >=20 > in a previous thread, it was stated that there are=20 > (allagedly) 24 axes to test. a magicsoftware .pdf > was linked to, but not only is it a bit over my head, it=20 > requires projection on to planes as well as > axes. >=20 > is there a projectionontoaxesonly method? and if so, any=20 > hints as to what the 24 axes are? i've > only found about 10. >=20 >=20 > thanks, > raigan >=20 >=20 >=20 >=20 >  > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a=20 > single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual=20 > machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 
From: metanet metanet <metanet_gda@ya...>  20030718 15:13:40

hi, thanks so much! time to start implementing.... raigan p.s  i'm looking forward to that paper ;) Alen Ladavac <alengdalgs@...> wrote: Generally, when we were designing our separatingaxis colliders, we were following this idea: You need one separating axis for each possible pair of closest features (all combinations of vertexvertex, vertexface, etc). Canonically, for boxbox, each box has 6 faces, 12 edges and 8 vertices, it would give you (6+12+8)^2=676 combinations. In most cases, a lot of combinations are usually represented by the same axis. E.g, one axis of box A handles separation of its two faces against all other features on box B. That's why the boxbox collider ends up with only 15 axis. For cylinderbox, there are 6 box faces, 12 box edges, 8 box vertices, 2 cylinder flat surfaces (top and bottom), 1 cylinder shell (is this the right word for the curved surface on the cylinder?) and 2 cylinder's circle edges (the sharp helix along the end of the cylinder shell). That would give (6+12+8)*(2+1+2)=130 axes. Unfortunately, these don't merge as easily as boxbox, so we actually have 39 (!) axes. The 24 axes I mentioned in the post you refer to, are just that last 24 (2x12) "box edge vs. cylinder circle edge" axes that bothered me. Here's the whole set: 1) 3 box axes  they handle box faces against all cylinder features, 2) 1 cylinder axis  handles the top and bottom ends of the cylinder against all box features, 3) 3 cross products of cylinder axis with box axes  they handle cylinder shell against box edges 4) 8 axis through the box vertices orthogonal to cylinder axis  handle vertices against the cylinder shell 5) 12 axes that are orthogonal to each edge of box and cylinder's top circle edge 6) 12 axes that are orthogonal to each edge of box and cylinder's bottom circle edge This uses only projection onto axes, and there is no numerical root finding involved  the solution is completely analytical. The axes in 5) and 6) are a bit more complicated to derive than the others, but not nearly as hard to understand as the rootfinding methods proposed in the paper from MagicSoftware website (all praises to Mr. Eberly, as I honor his work a lot, but some parts are just too complicated for something I'd have in my collider's inner loop :)). All other axes are simple and straight forward. I don't claim to have a mathematical proof of the correctness of the method, or to say that it is faster than numerical methods. But it certainly works for us so far, it is _very_ simple to implement, works in constant bounded time, and offers a lot of earlyouts. Also, there is a great potential in quickly discarding most of the axes in 4), 5) and 6). I believe that only 1 out of 8 in 4), and 1 out of 24 in 5) and 6) are relevant. But it will need to wait until this starts choking on some more complex scenes, so we are forced to devote time to optimizing it. :) If anyone finds a problem with this, or sees some optimization, please do let me know. I plan to make a document explaining all the colliders we use (sphere, box, capsule, cylinder, mesh), together with the actual contact point and penetration depth computations. I'd like to have that public so that it can be verified, and also to help putting an end to this neverending secrecy around simple and robust collision detection methods. Unfortunately, I don't have that much spare time right now, so I'll just resort to short (?) discussions like this. Alen  Original Message  From: metanet metanet To: gdalgorithmslist@... Sent: Thursday, July 17, 2003 7:00 PM Subject: [Algorithms] seperating axes with cylinders hi, i'm currently trying to find all seperating axes that need to be checked for boxcylinder intersection. in a previous thread, it was stated that there are (allagedly) 24 axes to test. a magicsoftware .pdf was linked to, but not only is it a bit over my head, it requires projection on to planes as well as axes. is there a projectionontoaxesonly method? and if so, any hints as to what the 24 axes are? i've only found about 10. thanks, raigan  This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188  Post your free ad now! Yahoo! Canada Personals 
From: Simon Fenney <simonf@vi...>  20030718 09:47:11

John Pollard [mailto:johnp@...] wrote: >This is kind of a noob question, but how are you folks solving >the problem where you get tearing from EMBM sampling? For >example, in the pixel shader you have code that uses another >texture (a normal map) to perturb the uv's for the next stage. > Some pixels will get shifted up, while others will get >shifted down. Even with filtering turned on, the filtering is >also shifted, so you get obvious tearing, which looks really >ugly close up. I think what you may be after are the dsx and dsy (SP?) frag/pixel shader functions/instructions  I believe you can use them to compute approximate "derivatives" of your perturbed texture sample locations and so choose the appropriate map level. Simon 
From: Alen Ladavac <alengdalgs@cr...>  20030718 06:04:38

Generally, when we were designing our separatingaxis colliders, we were following this idea: You need one separating axis for each possible pair of closest features (all combinations of vertexvertex, vertexface, etc). Canonically, for boxbox, each box has 6 faces, 12 edges and 8 vertices, it would give you (6+12+8)^2=676 combinations. In most cases, a lot of combinations are usually represented by the same axis. E.g, one axis of box A handles separation of its two faces against all other features on box B. That's why the boxbox collider ends up with only 15 axis. For cylinderbox, there are 6 box faces, 12 box edges, 8 box vertices, 2 cylinder flat surfaces (top and bottom), 1 cylinder shell (is this the right word for the curved surface on the cylinder?) and 2 cylinder's circle edges (the sharp helix along the end of the cylinder shell). That would give (6+12+8)*(2+1+2)=130 axes. Unfortunately, these don't merge as easily as boxbox, so we actually have 39 (!) axes. The 24 axes I mentioned in the post you refer to, are just that last 24 (2x12) "box edge vs. cylinder circle edge" axes that bothered me. Here's the whole set: 1) 3 box axes  they handle box faces against all cylinder features, 2) 1 cylinder axis  handles the top and bottom ends of the cylinder against all box features, 3) 3 cross products of cylinder axis with box axes  they handle cylinder shell against box edges 4) 8 axis through the box vertices orthogonal to cylinder axis  handle vertices against the cylinder shell 5) 12 axes that are orthogonal to each edge of box and cylinder's top circle edge 6) 12 axes that are orthogonal to each edge of box and cylinder's bottom circle edge This uses only projection onto axes, and there is no numerical root finding involved  the solution is completely analytical. The axes in 5) and 6) are a bit more complicated to derive than the others, but not nearly as hard to understand as the rootfinding methods proposed in the paper from MagicSoftware website (all praises to Mr. Eberly, as I honor his work a lot, but some parts are just too complicated for something I'd have in my collider's inner loop :)). All other axes are simple and straight forward. I don't claim to have a mathematical proof of the correctness of the method, or to say that it is faster than numerical methods. But it certainly works for us so far, it is _very_ simple to implement, works in constant bounded time, and offers a lot of earlyouts. Also, there is a great potential in quickly discarding most of the axes in 4), 5) and 6). I believe that only 1 out of 8 in 4), and 1 out of 24 in 5) and 6) are relevant. But it will need to wait until this starts choking on some more complex scenes, so we are forced to devote time to optimizing it. :) If anyone finds a problem with this, or sees some optimization, please do let me know. I plan to make a document explaining all the colliders we use (sphere, box, capsule, cylinder, mesh), together with the actual contact point and penetration depth computations. I'd like to have that public so that it can be verified, and also to help putting an end to this neverending secrecy around simple and robust collision detection methods. Unfortunately, I don't have that much spare time right now, so I'll just resort to short (?) discussions like this. Alen  Original Message  From: metanet metanet To: gdalgorithmslist@... Sent: Thursday, July 17, 2003 7:00 PM Subject: [Algorithms] seperating axes with cylinders hi, i'm currently trying to find all seperating axes that need to be checked for boxcylinder intersection. in a previous thread, it was stated that there are (allagedly) 24 axes to test. a magicsoftware .pdf was linked to, but not only is it a bit over my head, it requires projection on to planes as well as axes. is there a projectionontoaxesonly method? and if so, any hints as to what the 24 axes are? i've only found about 10. thanks, raigan 
From: Neil Stewart <neil@r0...>  20030718 01:03:19

I think most of the newer hardware calculates the derivatives by rasterising several pixels in lockstep (e.g. a 2x2 arrangement with 4 pixel pipes), so that the hardware registers at every stage of a pixel shader (fragment program) are known for all pipes. When an arbitrary calculation results in a texture lookup, the hardware knows where the lookups are occurring in all the pipes and can calculate the derivatives from this. You can also calculate and specify the derivatives in D3D, if you have the right hardware.  Neil.  Original Message  From: "Jon Watte" <hplus@...> To: <gdalgorithmslist@...> Sent: Thursday, July 17, 2003 11:41 PM Subject: RE: [Algorithms] EMBM filtering problems Actually, OpenGL calls them fragment programs, but no real difference. The algorithmic problem is this: when you perturb normals perfragment, and do texture lookups using dependent reads in general, it's hard for the hardware to do a good job of finding appropriate partial derivatives WRT your texture coordinates, so it's hard to select the appropriate MIP map levels or anisotropic sampling parameters. It's hard enough for cube maps, but can be done, because the perpixel variation is known, but for an arbitrary program, you have to help it out. There are NVIDIA specific fragment program extensions that allow you to actually specify derivatives for interpolation, if I remember correctly. However, that only benefits OpenGL programs running on NVIDIA cards. For a general solution to this problem, you have to figure out what the appropriate sampling function is yourself, and implement the filtering as part of your per fragment operation. You may also be able to adjust texture hardware LOD bias to make it "blurrier" to compensate for this. I forget the details per API, but some hardware also supports perlookup LOD bias, which would help you a lot if you could detect where to use it. I think this is a perfectly appropriate question for this list, and I think it can be answered in mostly API/hardwareagnostic terms. Let me know if you have another opinion  or a better solution :) Cheers, / h+ 