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
(31) 
2
(28) 
3
(10) 
4
(15) 
5
(22) 
6
(21) 
7
(30) 
8
(30) 
9
(44) 
10
(6) 
11
(5) 
12
(50) 
13
(33) 
14
(61) 
15
(68) 
16
(43) 
17
(24) 
18
(14) 
19
(85) 
20
(33) 
21
(30) 
22
(38) 
23
(1) 
24
(5) 
25
(6) 
26
(6) 
27
(29) 
28
(34) 
29
(81) 
30
(61) 
31
(10) 
From: Pierre Terdiman <p.terdiman@wa...>  20010310 23:22:22

Interesting.... If I find some time, I may try to implement something like this. I hope it will be faster than the GJK code alone..... The face/face test may take advantage of a nice little routine in PQP, which computes the closest points between 2 triangles. [Coded by Eric Larsen, based on ideas from Vladimir Lumelsky]. It yields the same results as a bruteforce GJK on 2 triangles, but it's about an order of magnitude faster. It it also more accurate: when triangles overlap the returned distance is exactly 0.0, which is not the case with a standard GJK. (Don't know for Cameron's one since I don't use it). The only thing is, I don't think one can freely use code snippets from PQP like that ! Pierre Terdiman * Home: p.terdiman@... Coder in the dark * Zappy's Lair: http://www.codercorner.com PS: and now that I'm writting about it....... I didn't realize this before, but maybe feeding PQP with 2 OBBs can work well......?  Original Message  From: Eric Haines <erich@...> To: <gdalgorithmslist@...> Sent: Saturday, March 10, 2001 8:15 PM Subject: Re: [Algorithms] Distance between 2 OBBs > Pierre, > > At 01:31 AM 3/7/01 +0100, you wrote: > >Is there some standard code available somewhere to compute the distance > >between 2 OBBs ? For the moment I'm using a generic GJK algo, and something > >a bit more dedicated to this particular task (and hopefully faster) would be > >welcome. > > I was hoping someone would have a good answer to this one  shucks, nothing. > > About all I've figured out is this (which is pretty obvious in retrospect, > but hey I was thinking about it first when I woke up in the middle of the > night. Annoyingly, it didn't help me fall back to sleep): > > Say you have OBBs A and B. A's faces define 6 planes. If object B is > entirely to one side of one of A's planes, then that face of A *must* > contain a point which is closest to B. So if for example B is entirely > above the top of A, some point on A's top face must be the closest approach > to B. This works for OBBs precisely because they're boxes, and is easy to > prove, so I won't bother. Anyway, this helps a little: if you know that the > closest point is on a face of A, then you don't have to feed the whole A > OBB to GJK, for example, but just the face of A. > > Note that B can be tested against A's planes in the usual fast ways  as I > recall you only need to test the closest corner of B, which is found by > looking at the four diagonals of B and seeing which aligns the most with > the normal of A's plane (see our book). > > You can go further: if object B is fully outside two planes of A, then the > closest point on A must lie on the edge shared by these two faces. If > you're really lucky and B is fully outside all three planes of A, then the > corner shared by these three faces on A is the closest approach to B. You > can obviously reverse the test and also get the closest face/edge/point, if > any, on B compared to A. > > If you're lucky enough to get the closest point for A (or B), it's trivial > to get the closest point on B (or A). Say you have the closest corner on A, > call it PA. You then tranform it into B's space and compare its extents in > each dimension. For example, if point PA is lower than B's X extents, > higher than B's Y extents, and in between B's Z extents in value, then the > closest point on B is (Bmin.X, Bmax.Y, PA.Z), where min is the minimum of > the extents and max the maximum. This is simply Arvo's sphere/box distance > test from Graphics Gems. So point vs. OBB is easy and quick. > > If you find a closest face or edge on both A and B, then it's also pretty > easy to determine the distance between the two: I leave it to you to solve > the closest distance for all these combinations. The face/face test is > maybe a little tricky, I haven't thought it through, but rest seem pretty > straightforward, especially since you know the objects don't intersect > (they can't, because of the plane clipping). > > That said, if the plane clip test fails entirely, i.e. you find that > neither object is entirely to one side of any plane of the other object, > I'd break out the GJK code at > http://users.comlab.ox.ac.uk/stephen.cameron/distances.html and call it a > day. The stuff I outlined above gives a quick answer if you can find a > clipping plane, and objects far away will tend to very quickly yield a > closest distance (because usually one corner will quickly be identified as > being the closest to the other OBB). > > Don't know if this helps (or even if it's right!), but I thought I'd pass > on my scattered thoughts, > > Eric > > > 
From: <corrosif@al...>  20010310 20:42:49

Thanks a lot Corrosif >We use the cross product of gradients computed with Sobel filters in >our tool, which is at the following URL (with source): >http://www.ati.com/na/pages/resource_centre/dev_rel/sdk/RadeonSDK/Html/T >ools/ToolsPlugIns.html > Jason >P.S. Beware URL truncation 
From: Jason Mitchell (ATI Technologies) <vjmitch@mi...>  20010310 20:38:28

We use the cross product of gradients computed with Sobel filters in our tool, which is at the following URL (with source): http://www.ati.com/na/pages/resource_centre/dev_rel/sdk/RadeonSDK/Html/T ools/ToolsPlugIns.html Jason P.S. Beware URL truncation > Original Message > From: corrosif@... [mailto:corrosif@...] > Sent: Saturday, March 10, 2001 12:06 PM > To: gdalgorithmslist@... > Subject: [Algorithms] Bumpmapping generation >=20 >=20 > How generate a bump(dot3) texture from a texture like=20 > (bumpmaker from nvidia, the source for this part is not available)?=20 > =20 > Like i want generate the bump texture on the fly... > =20 > Thanks > Corrosif 
From: <corrosif@al...>  20010310 20:12:36

How generate a bump(dot3) texture from a texture like (bumpmaker from nvidia, the source for this part is not available)? Like i want generate the bump texture on the fly... Thanks Corrosif 
From: Eric Haines <erich@ac...>  20010310 19:11:34

Pierre, At 01:31 AM 3/7/01 +0100, you wrote: >Is there some standard code available somewhere to compute the distance >between 2 OBBs ? For the moment I'm using a generic GJK algo, and something >a bit more dedicated to this particular task (and hopefully faster) would be >welcome. I was hoping someone would have a good answer to this one  shucks, nothing. About all I've figured out is this (which is pretty obvious in retrospect, but hey I was thinking about it first when I woke up in the middle of the night. Annoyingly, it didn't help me fall back to sleep): Say you have OBBs A and B. A's faces define 6 planes. If object B is entirely to one side of one of A's planes, then that face of A *must* contain a point which is closest to B. So if for example B is entirely above the top of A, some point on A's top face must be the closest approach to B. This works for OBBs precisely because they're boxes, and is easy to prove, so I won't bother. Anyway, this helps a little: if you know that the closest point is on a face of A, then you don't have to feed the whole A OBB to GJK, for example, but just the face of A. Note that B can be tested against A's planes in the usual fast ways  as I recall you only need to test the closest corner of B, which is found by looking at the four diagonals of B and seeing which aligns the most with the normal of A's plane (see our book). You can go further: if object B is fully outside two planes of A, then the closest point on A must lie on the edge shared by these two faces. If you're really lucky and B is fully outside all three planes of A, then the corner shared by these three faces on A is the closest approach to B. You can obviously reverse the test and also get the closest face/edge/point, if any, on B compared to A. If you're lucky enough to get the closest point for A (or B), it's trivial to get the closest point on B (or A). Say you have the closest corner on A, call it PA. You then tranform it into B's space and compare its extents in each dimension. For example, if point PA is lower than B's X extents, higher than B's Y extents, and in between B's Z extents in value, then the closest point on B is (Bmin.X, Bmax.Y, PA.Z), where min is the minimum of the extents and max the maximum. This is simply Arvo's sphere/box distance test from Graphics Gems. So point vs. OBB is easy and quick. If you find a closest face or edge on both A and B, then it's also pretty easy to determine the distance between the two: I leave it to you to solve the closest distance for all these combinations. The face/face test is maybe a little tricky, I haven't thought it through, but rest seem pretty straightforward, especially since you know the objects don't intersect (they can't, because of the plane clipping). That said, if the plane clip test fails entirely, i.e. you find that neither object is entirely to one side of any plane of the other object, I'd break out the GJK code at http://users.comlab.ox.ac.uk/stephen.cameron/distances.html and call it a day. The stuff I outlined above gives a quick answer if you can find a clipping plane, and objects far away will tend to very quickly yield a closest distance (because usually one corner will quickly be identified as being the closest to the other OBB). Don't know if this helps (or even if it's right!), but I thought I'd pass on my scattered thoughts, Eric 
From: Jay Patel <Jpatel@bl...>  20010310 03:58:47

That is slick. jay Original Message From: Gil Gribb [mailto:ggribb@...] Sent: Friday, March 09, 2001 6:29 AM To: gdalgorithmslist@... Subject: Re: [Algorithms] Extracting frustum planes from a matrix The "transforming planes" derivation seem sound to me, but I actually came up with this from a different angle. Using the opengl way of writing things: clip_space_point = M * local_space_point local_space_point is a 4 vector with a one in the last component. Break this down into components: clip_space_point.x = row(M,0) dot local_space_point clip_space_point.y = row(M,1) dot local_space_point clip_space_point.z = row(M,2) dot local_space_point clip_space_point.w = row(M,3) dot local_space_point Now lets look at the clip space inequalities: w<x<w w<y<w w<z<w You look at these one at a time. I'll just do x<w: clip_space_point.x < clip_space_point.w substitute in from above row(M,0) dot local_space_point < row(M,3) dot local_space_point do some algebra 0 < row(M,3) dot local_space_point  row(M,0) dot local_space_point 0< (row(M,3)  row(M,0)) dot local_space_point Now this is in the form of a plane equation with the 4 coefficients being (row(M,3)  row(M,0)) Then you do something similar for the other 5 planes. The plane equations you get are not normalized....i.e. the normal is not of unit length. For culling you don't need to worry about it. If you want a normalized plane equation, divide all 4 coefficients by the length of the plane normal. Gil > At 10:39 PM 3/8/01 0800, Eric Lengyel wrote: > >This whole thing about frustum plane extraction from the projection matrix > >is a snap if you look at it in the following way. Let P be the 4x4 > >projection matrix which transforms points from eye space into normalized > >clip space. Then Inverse(P) transforms points from clip space into eye > >space. The frustum planes in clip space are dirt simple: > > > >left = (1,0,0,1) > >right = (1,0,0,1) > >top = (0,1,0,1) > >bottom = (0,1,0,1) > >near = (0,0,1,1) > >far = (0,0,1,1) > > > >This is because the view frustum is a cube centered on the origin in clip > >space and each plane is one unit from the origin. > > Aha, this is what I didn't get  the derivation is based on using known > clip space planes and computing the inverse transform that takes them into > eye space. This presumes that you have inward facing normals and a > lefthanded clip space coordinate system, however. Something to be careful > of (OpenGL is natively righthanded, but I think it switches to lefthanded > for clip space...I'll have to look that up though). > > >Now planes are > >transformed using the inverse transpose of a matrix, so to transform these > >planes from clip space into eye space, we need to use > >Transpose(Inverse(Inverse(P))) = Transpose(P). Thus, the coefficients of > >the above planes tell us by what to multiply each column of Transpose(P), > >which are also the rows of P itself. So using the notation P[i] to > >represent (zerobased) row i of P, we have for the eye space frustum planes: > > > >left = P[0] + P[3] > >right = P[0] + P[3] > >top = P[1] + P[3] > >bottom = P[1] + P[3] > >near = P[2] + P[3] > >far = P[2] + P[3] > > There's a bit that gets muddled in here, so please bear with me. Are you > assuming that P is initially a row major matrix, or are you thinking it's > an OpenGL style column major matrix that happens to be used in a row major, > righthanded system? =) > > Factoring out any API specifics, let's assume that M is a row major matrix > such that: > > M*v = c > > where 'v' is a point in object space and 'c' is the final clipspace > coordinate. M is the matrix that goes from object space to clip space (in > OpenGL terms, this is the concatenation of the modelview and projection > matrices). > > Now, to go from clip space to object space we need to take the Transpose of > M and multiply it against the clip space planes. > > T*c = f (where T = Transpose(M)) > > left.clip = (1,0,0,1) > therefore > left.object = T*left.clip = M.column0 + M.column3 > > Does that seem correct? > > Brian Hook > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 