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
(17) 
2
(3) 
3
(4) 
4
(14) 
5
(12) 
6
(16) 
7
(28) 
8
(28) 
9
(12) 
10
(5) 
11
(17) 
12
(16) 
13
(37) 
14
(26) 
15
(10) 
16
(1) 
17
(2) 
18
(11) 
19
(9) 
20
(22) 
21
(14) 
22
(23) 
23
(4) 
24
(2) 
25
(16) 
26
(6) 
27
(3) 
28
(5) 
29
(4) 
30
(2) 
From: Thatcher Ulrich <tu@tu...>  20021112 19:43:03

On Nov 12, 2002 at 06:09 0000, Nick Pelling wrote: > Hi everyone, > > The challenge: given a desired intraobject nearest separation distance (d), > approximate an arbitrary triangle { x1, x2, x3 } with a set of (roughly > equallyspaced) point masses. > > Is there a reasonably direct algorithm for this, without going into a whole > simulatedannealing/electrostaticrepulsiontypeofalgorithm thing? > > If you start with an equilateral triangle (and divide each edge equally), > it's trivial... but try the same with (say) a 3:4:5 triangle, and it's not > *quite* so simple any more... :/ > > If this problem has a known name, that would be handy too. :o Rasterization? Heh :) Dunno if that's actually a practical solution to your problem, but I couldn't resist...  Thatcher Ulrich http://tulrich.com 
From: Peter Warden <pwarden@ku...>  20021112 19:34:27

If you were willing to have the points lie exactly on a grid, doing a software render of the triangle in the plane it lies in with imaginary pixels that are 'd' wide seems like it would satisfy your requirements? It wouldn't produce very 'pretty' arrangements of point masses though, they wouldn't be on the edges, and you might have no points for triangles less than 'd' in size, but I don't know if this matters for your application... Pete Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Nick Pelling Sent: Tuesday, November 12, 2002 10:09 AM To: 'gdalgorithmslist@...' Subject: [Algorithms] How do you best approximate a triangle's area with many roughlye quallyspaced point masses? Hi everyone, The challenge: given a desired intraobject nearest separation distance (d), approximate an arbitrary triangle { x1, x2, x3 } with a set of (roughly equallyspaced) point masses. Is there a reasonably direct algorithm for this, without going into a whole simulatedannealing/electrostaticrepulsiontypeofalgorithm thing? If you start with an equilateral triangle (and divide each edge equally), it's trivial... but try the same with (say) a 3:4:5 triangle, and it's not *quite* so simple any more... :/ If this problem has a known name, that would be handy too. :o Thanks!, .....Nick Pelling.....  This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: <christer_ericson@pl...>  20021112 19:13:45

Andreas Brinck said in response to Oscar Cooper: >>The usual fix is to add a degree of tolerance to the test: >> const float epsilon = 1.0e6f; >> if (distance > (total_projection + epsilon)) return false; >> >Actually this was my first thought too. I'm not sure I like though since the >obbs are so clearly intersecting (one is totally inside the other). This >solution seems somewhat fragile, one can never be sure that the epsilon is >enough to correctly resolve all situations. There must be an alternative way >to express the algorithm so that it is more stable without introducing >epsilon values. This is a notsowell known problem with the separatingaxis test. Whenever you compute the edgeedge test axes through cross product you get robustness problems when the result of the cross product approaches the zero vector. So it doesn't just apply to OBBOBB tests, but to all tests that are based on separating axis tests. Let L be a zero vector separating axis. Then the projections onto this axis should result in a test of "0 > 0" which should fail (assuming real arithmetic). However, in practice, with fp arithmetic, the zero vector is a "nearzero vector" and together with various rounding errors what you have is "0+eps1 > 0+eps2" which could swing either way. You can fix this by, as Oscar said, adding a carefully selected epsilon term to the righthand side. When the numbers are near zero, this epsilon term will be dominant and the righthand side will become larger than the lefthand side and it will cause the nearzero cases to fail properly, as they should. When the numbers are not near zero, the epsilon term will be dwarfed by the righthand side value and simply disappear and the test will work just as you'd expect it to. So, the bottom line is that adding an epsilon test as suggested by Oscar, in general is robust, when done correctly. Christer Ericson Sony Computer Entertainment, Santa Monica 
From: Nick Pelling <NP<elling@cl...>  20021112 18:09:03

Hi everyone, The challenge: given a desired intraobject nearest separation distance (d), approximate an arbitrary triangle { x1, x2, x3 } with a set of (roughly equallyspaced) point masses. Is there a reasonably direct algorithm for this, without going into a whole simulatedannealing/electrostaticrepulsiontypeofalgorithm thing? If you start with an equilateral triangle (and divide each edge equally), it's trivial... but try the same with (say) a 3:4:5 triangle, and it's not *quite* so simple any more... :/ If this problem has a known name, that would be handy too. :o Thanks!, .....Nick Pelling..... 
From: Nick Pelling <NP<elling@cl...>  20021112 17:56:33

Even though Sony's PS1 float library calls were diabolically slow, they were still many times faster than their double library calls. "realtime" was not exactly the adjective you'd use to describe them. :/ Ermm... how things change, eh? :9 Cheers, .....Nick Pelling..... Original Message From: Tyson Jensen [mailto:twjensen@...] Sent: 12 November 2002 17:44 To: gdalgorithmslist@... Subject: RE: [Algorithms] RE:acos function  double to float tip 10 SECONDS faster?! What did the init loop do? Call out to Japan for the correct numbers? That must have been one big table! Or maybe PS1 is less powerful than I remember . . . ;) 
From: Tyson Jensen <twjensen@sa...>  20021112 17:44:19

10 SECONDS faster?! What did the init loop do? Call out to Japan for the correct numbers? That must have been one big table! Or maybe PS1 is less powerful than I remember . . . ;) Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Nick Pelling Sent: Tuesday, November 12, 2002 3:15 AM To: 'gdalgorithmslist@...' Subject: RE: [Algorithms] RE:acos function  double to float tip printf()/scanf() aside, another idea is to create filtered maths libraries, with all double accepting/returning functions removed. And another idea (which is what Paul Shirley and I used) was simply to profile it and gasp in horror whenever a load of doubleusing code hogs the CPU. On the PS1, I remember Paul converting a cos() table init loop to a static table of floats, and being somewhat surprised when the game started up (at least) 10 seconds faster. :) Cheers, .....Nick Pelling.....  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Brinck, Andreas <Andreas.B<rinck@di...>  20021112 15:34:21

I just got a response from Dave Eberly on how to fix this in a pretty solid way. His suggestion was to add a boolean flag if the axes of the obbs are nearly parallell and in that case skip the 6 tests involving the planes built from one edge of each obb. His updated source code is available at http://www.magicsoftware.com/Intersection3D.html . /A.B. Original Message From: Kent Quirk [mailto:kent_quirk@...] Sent: den 12 november 2002 16:03 To: gdalgorithmslist@... Subject: Re: [Algorithms] Obb vs. obb test numerically unstable? This makes me slap my head and go "DOH!" Three years ago, I ran into exactly the same problem. I had implemented what seemed to me to be a very robust OBB CD system...and had it fail in ways I couldn't explain. It worked most of the time, but sometimes collisions would miss for a couple of frames, and then suddenly collide after things had interpenetrated too far to escape. In weird cases, I'd actually have vehicles glide through walls as if they weren't there. Numerical inaccuracy never even occurred to me as a possible solution. I beat on this for weeks trying to find where I'd misimplemented a test. Wrote tons of test code, but never quite came to this conclusion. I ended up falling back to a much less satisfactory solution, and now I'm kicking myself. I WOULD be interested to hear what other people have used for a solution. Kent Tuesday, November 12, 2002, 6:08:55 AM, gdalgorithmslist wrote: >> I have a problem with my obb vs. obb collision detection. Sometimes when >> the obbs have almost exact the same orientation and in reality do >> intersect the test incorrectly reports that they don't. The problem seems >> to be caused by numerical inaccuracies. I use the standard separating axis >> method for the test. >> >> Here's an example of two obbs that incorrectly gets reported as not >> intersecting: >> >> Obb 1: >> X Y Z T : (1.0f, 0.0f, 0.0f), (2.1e18, 1.0f, 3.0e6), (0.0f, 3.0e6, >> 1.0f), (0.0f, 0.0f, 0.0f) >> Extents : (5.1f, 20.2f, 1.6f) >> >> Obb 2: >> X Y Z T : (1.0f, 0.0f, 0.0f), (0.0f, 1.0f, 0.0f), (0.0f, 0.0f, 1.0f), >> (18.4f, 2.6f, 16.6f) >> Extents (53.6f, 78.9f, 53.6f) >> >> Anyone has an idea on how to solve this in a robust way (i.e. not >> switching to using doubles)? I've also tested with the "bool >> Mgc::TestIntersection (const Box3& rkBox0, const Box3& rkBox1)"function >> from http://www.magicsoftware.com and it has exactly the same problems. >> >> /A.B. >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188  Kent Quirk, CTO, CogniToy kent_quirk@... http://www.cognitoy.com  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Kent Quirk <kent_quirk@co...>  20021112 15:03:47

This makes me slap my head and go "DOH!" Three years ago, I ran into exactly the same problem. I had implemented what seemed to me to be a very robust OBB CD system...and had it fail in ways I couldn't explain. It worked most of the time, but sometimes collisions would miss for a couple of frames, and then suddenly collide after things had interpenetrated too far to escape. In weird cases, I'd actually have vehicles glide through walls as if they weren't there. Numerical inaccuracy never even occurred to me as a possible solution. I beat on this for weeks trying to find where I'd misimplemented a test. Wrote tons of test code, but never quite came to this conclusion. I ended up falling back to a much less satisfactory solution, and now I'm kicking myself. I WOULD be interested to hear what other people have used for a solution. Kent Tuesday, November 12, 2002, 6:08:55 AM, gdalgorithmslist wrote: >> I have a problem with my obb vs. obb collision detection. Sometimes when >> the obbs have almost exact the same orientation and in reality do >> intersect the test incorrectly reports that they don't. The problem seems >> to be caused by numerical inaccuracies. I use the standard separating axis >> method for the test. >> >> Here's an example of two obbs that incorrectly gets reported as not >> intersecting: >> >> Obb 1: >> X Y Z T : (1.0f, 0.0f, 0.0f), (2.1e18, 1.0f, 3.0e6), (0.0f, 3.0e6, >> 1.0f), (0.0f, 0.0f, 0.0f) >> Extents : (5.1f, 20.2f, 1.6f) >> >> Obb 2: >> X Y Z T : (1.0f, 0.0f, 0.0f), (0.0f, 1.0f, 0.0f), (0.0f, 0.0f, 1.0f), >> (18.4f, 2.6f, 16.6f) >> Extents (53.6f, 78.9f, 53.6f) >> >> Anyone has an idea on how to solve this in a robust way (i.e. not >> switching to using doubles)? I've also tested with the "bool >> Mgc::TestIntersection (const Box3& rkBox0, const Box3& rkBox1)"function >> from http://www.magicsoftware.com and it has exactly the same problems. >> >> /A.B. >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188  Kent Quirk, CTO, CogniToy kent_quirk@... http://www.cognitoy.com 
From: Angel Popov <geleto@ge...>  20021112 13:37:32

I've had great results when combining area (not volume!) preservation with the Hoppe's new QEM using this metric: if( oldArea>newArea ) error=qem_error*(1+K*( oldAreanewArea )/oldArea); else error=qem_error*(1+K*( newAreaoldArea )/newArea); where oldArea and newArea are the areas of the tris involved in the collapse. The value of K that I use is 100 See this screenshot (the first row is generated using area preservation): http://www.picturetrail.com/gallery/view?p=3&uid=770811&gid=1346743&imgid=15 702197  Original Message  From: "Brian Marshall" <Brian.Marshall@...> To: "GdalgorithmsList (Email)" <gdalgorithmslist@...> Sent: Tuesday, November 12, 2002 12:39 PM Subject: [Algorithms] Volume Preservation during Progressive Mesh Construction > Currently, I'm handling volume preseveration using Hoppe's Volume > preservation constraint (From the paper "New Quadric Metric for Simplifying > Meshes with Appearance Attributes" Hugues Hoppe), which works quite well. > > However, I'd like better results at high levels of simplification. > > Currently, I'm thinking of trying permission grids. (From the paper > "Permission Grids: Practical, ErrorBounded Simplification" Steve > Zelinka/Michael Garland) > > Has anyone any experience of this, or any other alternatives for approaching > volume preservation? > > Brian. > > > >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Brinck, Andreas <Andreas.B<rinck@di...>  20021112 12:11:18

Actually this was my first thought too. I'm not sure I like though since the obbs are so clearly intersecting (one is totally inside the other). This solution seems somewhat fragile, one can never be sure that the epsilon is enough to correctly resolve all situations. There must be an alternative way to express the algorithm so that it is more stable without introducing epsilon values. /A.B. Original Message From: Oscar Cooper [mailto:oscar.cooper@...] Sent: den 12 november 2002 12:51 To: gdalgorithmslist@... Subject: RE: [Algorithms] Obb vs. obb test numerically unstable? I've seen similar behaviour when evaluating the separation along axes that are the cross product of approximately parallel vectors. If your separation test is: if (distance > total_projection) return false; then when the test axis has approximately zero length this reduces to: if (approximately_zero_a > approximately_zero_b) return false; The usual fix is to add a degree of tolerance to the test: const float epsilon = 1.0e6f; if (distance > (total_projection + epsilon)) return false; Original Message From: Brinck, Andreas [mailto:Andreas.Brinck@...] Sent: Tuesday, November 12, 2002 11:09 AM To: gdalgorithmslist@... Subject: [Algorithms] Obb vs. obb test numerically unstable? > I have a problem with my obb vs. obb collision detection. Sometimes when > the obbs have almost exact the same orientation and in reality do > intersect the test incorrectly reports that they don't. The problem seems > to be caused by numerical inaccuracies. I use the standard separating axis > method for the test. > > Here's an example of two obbs that incorrectly gets reported as not > intersecting: > > Obb 1: > X Y Z T : (1.0f, 0.0f, 0.0f), (2.1e18, 1.0f, 3.0e6), (0.0f, 3.0e6, > 1.0f), (0.0f, 0.0f, 0.0f) > Extents : (5.1f, 20.2f, 1.6f) > > Obb 2: > X Y Z T : (1.0f, 0.0f, 0.0f), (0.0f, 1.0f, 0.0f), (0.0f, 0.0f, 1.0f), > (18.4f, 2.6f, 16.6f) > Extents (53.6f, 78.9f, 53.6f) > > Anyone has an idea on how to solve this in a robust way (i.e. not > switching to using doubles)? I've also tested with the "bool > Mgc::TestIntersection (const Box3& rkBox0, const Box3& rkBox1)"function > from http://www.magicsoftware.com and it has exactly the same problems. > > /A.B.  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Oscar Cooper <oscar.cooper@cr...>  20021112 11:58:54

I've seen similar behaviour when evaluating the separation along axes that are the cross product of approximately parallel vectors. If your separation test is: if (distance > total_projection) return false; then when the test axis has approximately zero length this reduces to: if (approximately_zero_a > approximately_zero_b) return false; The usual fix is to add a degree of tolerance to the test: const float epsilon = 1.0e6f; if (distance > (total_projection + epsilon)) return false; Original Message From: Brinck, Andreas [mailto:Andreas.Brinck@...] Sent: Tuesday, November 12, 2002 11:09 AM To: gdalgorithmslist@... Subject: [Algorithms] Obb vs. obb test numerically unstable? > I have a problem with my obb vs. obb collision detection. Sometimes when > the obbs have almost exact the same orientation and in reality do > intersect the test incorrectly reports that they don't. The problem seems > to be caused by numerical inaccuracies. I use the standard separating axis > method for the test. > > Here's an example of two obbs that incorrectly gets reported as not > intersecting: > > Obb 1: > X Y Z T : (1.0f, 0.0f, 0.0f), (2.1e18, 1.0f, 3.0e6), (0.0f, 3.0e6, > 1.0f), (0.0f, 0.0f, 0.0f) > Extents : (5.1f, 20.2f, 1.6f) > > Obb 2: > X Y Z T : (1.0f, 0.0f, 0.0f), (0.0f, 1.0f, 0.0f), (0.0f, 0.0f, 1.0f), > (18.4f, 2.6f, 16.6f) > Extents (53.6f, 78.9f, 53.6f) > > Anyone has an idea on how to solve this in a robust way (i.e. not > switching to using doubles)? I've also tested with the "bool > Mgc::TestIntersection (const Box3& rkBox0, const Box3& rkBox1)"function > from http://www.magicsoftware.com and it has exactly the same problems. > > /A.B.  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Nick Pelling <NP<elling@cl...>  20021112 11:15:10

printf()/scanf() aside, another idea is to create filtered maths libraries, with all double accepting/returning functions removed. And another idea (which is what Paul Shirley and I used) was simply to profile it and gasp in horror whenever a load of doubleusing code hogs the CPU. On the PS1, I remember Paul converting a cos() table init loop to a static table of floats, and being somewhat surprised when the game started up (at least) 10 seconds faster. :) Cheers, .....Nick Pelling..... 
From: Brinck, Andreas <Andreas.B<rinck@di...>  20021112 11:09:07

> I have a problem with my obb vs. obb collision detection. Sometimes when > the obbs have almost exact the same orientation and in reality do > intersect the test incorrectly reports that they don't. The problem seems > to be caused by numerical inaccuracies. I use the standard separating axis > method for the test. > > Here's an example of two obbs that incorrectly gets reported as not > intersecting: > > Obb 1: > X Y Z T : (1.0f, 0.0f, 0.0f), (2.1e18, 1.0f, 3.0e6), (0.0f, 3.0e6, > 1.0f), (0.0f, 0.0f, 0.0f) > Extents : (5.1f, 20.2f, 1.6f) > > Obb 2: > X Y Z T : (1.0f, 0.0f, 0.0f), (0.0f, 1.0f, 0.0f), (0.0f, 0.0f, 1.0f), > (18.4f, 2.6f, 16.6f) > Extents (53.6f, 78.9f, 53.6f) > > Anyone has an idea on how to solve this in a robust way (i.e. not > switching to using doubles)? I've also tested with the "bool > Mgc::TestIntersection (const Box3& rkBox0, const Box3& rkBox1)"function > from http://www.magicsoftware.com and it has exactly the same problems. > > /A.B. 
From: Brian Marshall <Brian.M<arshall@wa...>  20021112 10:54:07

Currently, I'm handling volume preseveration using Hoppe's Volume preservation constraint (From the paper "New Quadric Metric for Simplifying Meshes with Appearance Attributes" Hugues Hoppe), which works quite well. However, I'd like better results at high levels of simplification. Currently, I'm thinking of trying permission grids. (From the paper "Permission Grids: Practical, ErrorBounded Simplification" Steve Zelinka/Michael Garland) Has anyone any experience of this, or any other alternatives for approaching volume preservation? Brian. 
From: Gottfried Chen <gottfried.chen@ne...>  20021112 10:01:18

What we currently do and looks ok: The color texture contains all = details painted in but lit with ambient light only (so no particular = light direction is assumed and the contrast is low). So even when there = is no directional/point light, no details pop away and plain ambient = lighting is used. It still looks a bit flat but I think it's more = correct than assuming any light direction in ambient only cases. Gottfried > Urspr=FCngliche Nachricht > Von: Dan Baker [mailto:danbaker@...]=20 > Gesendet: Dienstag, 12. November 2002 07:50 > An: gdalgorithmslist@... > Betreff: RE: [Algorithms] Bump maps and ambient light >=20 >=20 > You can use the hemisphere lighting trick, works great for=20 > these scenarios >=20 > i.e. use a 2 color ambient term, one is the sky color, the=20 > other is the ground color. Take the dot product between the=20 > normal and the vertical (0,0,1), rerange it to go from 0 to 1=20 > (instead of 1 to 1) and then lerp between the sky and ground color. >=20 > Technically (if you work the integral of a 2 hemisphere=20 > lighting model), its supposed to be the sin, not the cos, but=20 > its hard to tell the difference.=20 >=20 > Dan >=20 > Original Message > From: Gottfried Chen [mailto:gottfried.chen@...]=20 > Sent: Monday, November 11, 2002 7:46 AM > To: gdalgorithmslist@... > Subject: [Algorithms] Bump maps and ambient light >=20 > When you use bump maps from a higher poly model and the model=20 > is placed into an area with ambient light only then there's=20 > the problem that the detail in this area is a lot lower then=20 > in lit places. What are good ways to solve this? >=20 >  Don't use ambient light (that's not possible for what we're=20 > doing, since we'd get big dark areas). >  Use a texture that has the detail painted into and=20 > switch/fade to this texture when you can't use dot3 lighting,=20 > though I don't think this'll look good. >  Light the model from a default direction in ambient only places. >=20 > Gottfried >=20 >=20 >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf=20 > _______________________________________________ > GDAlgorithmslist mailing list GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 >=20 >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf=20 > _______________________________________________ > GDAlgorithmslist mailing list GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 
From: Dan Baker <danbaker@wi...>  20021112 06:49:49

You can use the hemisphere lighting trick, works great for these scenarios i.e. use a 2 color ambient term, one is the sky color, the other is the ground color. Take the dot product between the normal and the vertical (0,0,1), rerange it to go from 0 to 1 (instead of 1 to 1) and then lerp between the sky and ground color. Technically (if you work the integral of a 2 hemisphere lighting model), its supposed to be the sin, not the cos, but its hard to tell the difference.=20 Dan Original Message From: Gottfried Chen [mailto:gottfried.chen@...]=20 Sent: Monday, November 11, 2002 7:46 AM To: gdalgorithmslist@... Subject: [Algorithms] Bump maps and ambient light When you use bump maps from a higher poly model and the model is placed into an area with ambient light only then there's the problem that the detail in this area is a lot lower then in lit places. What are good ways to solve this?  Don't use ambient light (that's not possible for what we're doing, since we'd get big dark areas).  Use a texture that has the detail painted into and switch/fade to this texture when you can't use dot3 lighting, though I don't think this'll look good.  Light the model from a default direction in ambient only places. Gottfried  This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 