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
(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: Scott Le Grand <varelse@be...>  20010829 23:41:16

At 02:15 PM 8/27/2001 0700, you wrote: >Yep. For example, physics in the game may run at 100hz or so no matter >what the graphics are doing. That means that it needs to run multiple >physics steps per frame. This is can be important both for simulation >stability and collision detection to prevent tunnelling. > >You definitely want to unlink the two. > >Jeff About 4 years ago, I interviewed at Atari Games at about the same time as San Francisco Rush had come out. I commented that it felt a bit like Hard Drivin'. Ed Logg replied that this was because they had lifted the code for the underlying physics right from that game. The difference was that running 1 car at 100 Hz in Hard Drivin' pinned the needle so to speak whereas they could now run 8 cars at 200 Hz with no difficulty. The challenge they faced at that time was cramming all of this into the N64. A third consideration for running independent of framerate is keeping a networked universe of players, on diverse hardware, in relative lockstep. Then there's the whole consideration of floating point versus SSE versus 3DNow, but we can save that for another day :)... >At 02:35 PM 8/27/2001 0500, you wrote: > >So as a rule, most simulations use time steps that are independent of other > >systems? As in the Graphics subsystem runs at 80 HZ and the physics > >simulation runs at say 25 hz with a fixed time step? > > > >Idahosa Edokpayi > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: Jeff Lander <jeffl@da...>  20010829 19:45:28

More then one developer I have talked to are completely afraid and unaware of even midpoint until I talked to them about it. At least two didn't even know they were integrating anything. "We just multiple the velocity times the time and get the new position". The one I am using now for one project is from a book by Jack Crenshaw. He worked on JPL/Nasa embedded systems type stuff and has great stories about broken integrators. His one that I really like uses the fact that the particle physics integration is a second order equation that we are using two first order equations to solve. Most schemes treat the two as independent. His stores the calculated force from the previous frame and uses that to calculate the velocity in a predictor fashion. Then the position calculation uses this velocity calc in a corrector sort of way. I don't have the code handy but it is a really easy formula. Almost the same as speed as forward Euler with only one function eval but you do need to store the previous force vector. Yet the stability is better than midpoint for my app (though not as stable as RK4 but also less damped). v(i+1) = v(i) + h/2(3f(i)  f(i1)) x(i+1) = x(i) + h/2(v(i+1) + v(i)) Looking it up in my algorithms book it seems that this is close to either a AdamsBashford 2 step explicit integrator or a velocity Verlet. Not too up on that but it works quite well. Jeff At 11:53 AM 8/29/2001 0700, you wrote: >At 08:59 AM 8/27/2001 0700, you wrote: >>Judging by the number of developers I have talked to that are still using forward Euler (even for connected rigid bodies in at least one car game...yikes) I think just moving to something like the predictorcorrector I use or midpoint would be a big step. > >Heh, what developers ARE you talking to? Pretty much everyone I know either uses or independently reinvented midpoint. It's like the Bresenham algorithm for physics integration IMO. Is your predictorcorrector any faster? > >Scott 
From: <christer_ericson@pl...>  20010829 19:36:52

"Vek" wrote: >Has anyone got any advice or links dealing with quad/octrees made of >overlapping circles/spheres rather than the 'traditional' quads? I mean the >actual 'spaces' the quadtree or octree is comprised of. There is overlap, >but I've found that with a little bit of flagging and bestfitting, I save a >lot of squarevscircle type checks. I'm wondering if there's a reason I've >seen very little talk about such, is there some sort of gotcha I'm not >seeing, looking just around the corner? Is there some way to optimize it >even more? I think the reason there isn't much available on these, is because they're only useful for certain applications. Doing a sphereAABB test is  after all  quite cheap, and if the tree is static, you're likely to win by keeping it as boxes rather than going with spheres, just because you have no overlap. For something like collision detection, using spheres can be beneficial as they are rotationally invariant, allowing you to freely transform your trees with little additional cost. A paper related to the latter is this one: C. Tzafestas and P. Coiffet. Real time collision detection using spherical octrees: virtual reality applications. In 5th IEEE International Workshop on Robot and Human Communication (ROMAN'96), pages 500506, Tsukuba, Japan, November 1996. It used to be available here: ftp://ftp.robot.uvsq.fr/pub/publications/articles/proc9625.ps.gz but I couldn't access it just now. However, there's a cached copy on CiteSeer. Christer Ericson Sony Computer Entertainment, Santa Monica 
From: Peter Prade <prade@ph...>  20010829 19:28:33

>>> Direction = Delta*1/Distance; // normed Directionvector from P2 to P1 >>> Because of this divide this algorithm will actually fail if the two spheres happen >>> to have the same center. This is a case that needs to be tested seperatelly. >> actually, this case is already handled (if the two spheres have the same >> center, the larger one will contain the other, and the divide won't get >> executed) >That's not true. Here is an excerpt of the code fragment to which I was >replying: Ooops, you're right, i was showing intermediate results for clearness and thus broke the code :) here's the corrected code: Delta = P1P2; Distance = Delta.Length(); // where Length calculates the Length of a vector if(r1>=r2+Distance) // sphere 2 contained in sphere 1 { P = P1; r = r1; } else if(r2>=r1+Distance) // sphere 1 contained in sphere 2 { P = P2; r = r2; } else { Direction = Delta*1/Distance; // normed Directionvector from P2 to P1 P = (P1+Direction*r1 + P2Direction*r2)/2; // Position of Bounding Sphere r = (r1+r2+Distance)/2; } 
From: Scott Le Grand <varelse@be...>  20010829 18:55:11

At 08:59 AM 8/27/2001 0700, you wrote: >Judging by the number of developers I have talked to that are still using >forward Euler (even for connected rigid bodies in at least one car >game...yikes) I think just moving to something like the >predictorcorrector I use or midpoint would be a big step. Heh, what developers ARE you talking to? Pretty much everyone I know either uses or independently reinvented midpoint. It's like the Bresenham algorithm for physics integration IMO. Is your predictorcorrector any faster? Scott 
From: Jorrit Tyberghein <Jorrit.Tyberghein@uz...>  20010829 18:53:02

Peter Prade wrote: > >> Direction = Delta*1/Distance; // normed Directionvector from P2 to P1 > >Because of this divide this algorithm will actually fail if the two spheres > happen > >to have the same center. This is a case that needs to be tested > seperatelly. > > actually, this case is already handled (if the two spheres have the same > center, the larger one will contain the other, and the divide won't get > executed) > That's not true. Here is an excerpt of the code fragment to which I was replying: > Delta = P1P2; > Distance = Delta.Length(); // where Length calculates the Length of a vector > Direction = Delta*1/Distance; // normed Directionvector from P2 to P1 > > if(r1>=r2+Distance) // sphere 2 contained in sphere 1 > { > It divide (1/Distance) happens BEFORE the test. Of course Direction is not used in the test so it it easy to delay the calculation of Direction to later but my point was that the original algo was not doing that. It was doing the divide before the tests. Greetings  ============================================================================== Jorrit.Tyberghein@..., University Hospitals KU Leuven BELGIUM He'd never realized that, deep down inside, what he really wanted to do was make things go splat.  (Terry Pratchett, Reaper Man) ============================================================================== 
From: Vek <vektuz@ho...>  20010829 18:21:52

Okay, it's been a while since I posted here but anyways... Has anyone got any advice or links dealing with quad/octrees made of overlapping circles/spheres rather than the 'traditional' quads? I mean the actual 'spaces' the quadtree or octree is comprised of. There is overlap, but I've found that with a little bit of flagging and bestfitting, I save a lot of squarevscircle type checks. I'm wondering if there's a reason I've seen very little talk about such, is there some sort of gotcha I'm not seeing, looking just around the corner? Is there some way to optimize it even more? Secondly, Zbuffer. Is there an algorythm more widely used to deal with zbuffer 'fighting' in 16 bit modes? My engine seems fine in 32 bit due to the nice and accurate buffer, but in 16bit its fighting a great deal... more than it should be, in my opinion. There are large chunks of objects zigzagging through each other even at close range. Is there some algo or filter (matrix / floating point op) that's known that would optimize it in 16bit for better ZBuffer compatibility? I can't think of any right now, considering the way the zbuffer works, but I'm sure something must be the matter  many other games which display ZFighting in 16bit show a lot less, even where objects overlap. Thank you for reading :) Nick Lawson vektuz@... 
From: Chris Haarmeijer <c.haarmeijer@ke...>  20010829 17:24:01

Hi, I have this weird problem. I tried to implement a firstpersonshooter camera using quaternions today and implemented two methods in my camera class:  AddPitch(angle_in_degrees)  AddYaw(angle_in_degrees) When my mouse moves in the Y direction, AddPitch is called with the appropriate movement delta and AddYaw is called in case of X movement. These methods do the following (in pseudocode): AddPitch/Yaw:  relative_rotation_quat = rotation quaternion with the amount of pitch or yaw specified  rotation_quat = rotation_quat * relative_rotation_quat This approach gives me faulty results when moving the camera at the start pitch=0 and yaw=90 (camera is parallel to Xaxis). When I move my mouse in the Y direction, pitch is changed but the camera does a roll instead of a pitch change. When I change the pitch method to do the following: AddPitch:  relative_rotation_quat = rotation quaternion with the amount of pitch or yaw specified  rotation_quat = relative_rotation_quat * rotation_quat And leave the AddYaw as is, then the whole thing works fine....... Now could anybody tell me what is going wrong?? Chris  Keep IT Simple Software Van Alphenstraat 12 7514 DD Enschede W: http://www.keepitsimple.nl E: mailto:info@... T: +31 53 4356687 
From: Charles Bloom <cbloom@cb...>  20010829 16:22:42

The colorspace matrix is one of the things that's an option in the PEG standards. You typically write it into the coded stream. There are, of course, defacto standards, which are taken from example code or examples in the standards. At 02:19 PM 8/29/2001 +0100, you wrote: > mpg streamer to our engine so the artists can build movies). I'm >assuming it's the standard RGB to YUV matrix  but there seem to be a >number of variations on this some of which offset and some don't. Whatever >they all look pretty washed out. David Hunt  Charles Bloom cb@... http://www.cbloom.com 
From: Peter Prade <prade@ph...>  20010829 14:19:00

>> Direction = Delta*1/Distance; // normed Directionvector from P2 to P1 >Because of this divide this algorithm will actually fail if the two spheres happen >to have the same center. This is a case that needs to be tested seperatelly. actually, this case is already handled (if the two spheres have the same center, the larger one will contain the other, and the divide won't get executed) Cheers, Peter 
From: Jorrit Tyberghein <Jorrit.Tyberghein@uz...>  20010829 13:37:40

Peter Prade wrote: > Well here is a simple algo to calculate the smallest bounding sphere for 2 > spheres: > > Suppose you have two Spheres at P1 and P2 with radii r1 and r2... > the bounding sphere (at Position P with radius r) is then calculated as > follows: > > Delta = P1P2; > Distance = Delta.Length(); // where Length calculates the Length of a vector > Direction = Delta*1/Distance; // normed Directionvector from P2 to P1 Because of this divide this algorithm will actually fail if the two spheres happen to have the same center. This is a case that needs to be tested seperatelly. Greetings,  ============================================================================== Jorrit.Tyberghein@..., University Hospitals KU Leuven BELGIUM Nanny Ogg never did any housework herself, but she was the cause of housework in other people.  (Terry Pratchett, Lords and Ladies) ============================================================================== 
From: David Hunt <david@hu...>  20010829 13:09:55

Just a quickie  does anybody know the correct colour conversion matrix = to convert from RGB to YUV12 which is an input format used by mpg = compressors (I'm adding an mpg streamer to our engine so the artists can = build movies). I'm assuming it's the standard RGB to YUV matrix  but there seem to be = a number of variations on this some of which offset and some don't. = Whatever they all look pretty washed out. David Hunt 
From: Konstantinos Goutzinopoulos <goutzi@ze...>  20010829 11:07:07

I am doing a table football simulator. I did the collusions with the walls and the players. I want to add more reality. Does anybody knows how to add spin in the ball? 
From: Aaron Drew <ripper@ho...>  20010829 10:55:03

Dave Elbery has some code at http://www.magicsoftware.com that does this. His book (3D Game Engine Design) has a short explaination of the algorithm. I can't say I completely understand it. He also has a more approximate calculation that is a bit faster. Cheers, Aaron Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Peter Prade Sent: Wednesday, August 29, 2001 8:17 PM To: gdalgorithmslist@... Subject: RE: [Algorithms] Bounding sphere of spheres Well here is a simple algo to calculate the smallest bounding sphere for 2 spheres: Suppose you have two Spheres at P1 and P2 with radii r1 and r2... the bounding sphere (at Position P with radius r) is then calculated as follows: Delta = P1P2; Distance = Delta.Length(); // where Length calculates the Length of a vector Direction = Delta*1/Distance; // normed Directionvector from P2 to P1 if(r1>=r2+Distance) // sphere 2 contained in sphere 1 { P = P1; r = r1; } else if(r2>=r1+Distance) // sphere 1 contained in sphere 2 { P = P2; r = r2; } else { P = (P1+Direction*r1 + P2Direction*r2)/2; // Position of Bounding Sphere r = (r1+r2+Distance)/2; } You should be able to extend that to more than 2 spheres just by iterating... Cheers, Peter Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of T.M. Evans Sent: Wednesday, August 29, 2001 10:36 AM To: gdalgorithmslist@... Subject: [Algorithms] Bounding sphere of spheres Is there any stupidly fast method of finding the bounding sphere of several spheres? Ashamed to admit it, I first find the bounding box and then the sphere from the box centre. Surely there are better ways. I'm not overly concerned with accuracy, slightly loose spheres would do fine if it's fast. _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: John Mckenna <jmckenna@re...>  20010829 10:26:22

>From: Peter Prade [mailto:prade@...] >Well here is a simple algo to calculate the smallest bounding >sphere for 2 spheres > >Suppose you have two Spheres at P1 and P2 with radii r1 and r2... >the bounding sphere (at Position P with radius r) is then calculated as >follows: [snip] >You should be able to extend that to more than 2 spheres just by >iterating... That's the algorithm given in Graphics Gems (I believe that was for points, not spheres, but it's a simple modification). It isn't exact, but the original poster was only after an approximation. Take your first two spheres. Find the bounding sphere of those. Then take it and your next sphere, find the bounding sphere of those two. Repeat until bored. A quick Google found this: http://geometryalgorithms.com/Archive/algorithm_0107/algorithm_0107.htm which looks like a nice simple explanation of lots of methods (for many bounding volumes  not just spheres), with a few references at the end if you need more. Virus scanned and cleared ok 
From: Kirill Prazdnikov <kirill@st...>  20010829 10:24:35

inline Sphere SphereUnion(const Sphere &s1, const Sphere &s2) { Vector3f dif = s1.os2.o; float dist = dif.Norma(); if (dist+s1.r <= s2.r ) return s2; if (dist+s2.r <= s1.r ) return s1; float radius = (dist+s1.r+s2.r)*0.5; Vector3f center = s2.o+dif*((radiuss2.r)/dist); return Sphere( center, radius); }  Original Message  From: "T.M. Evans" <tmadoc@...> To: <gdalgorithmslist@...> Sent: Wednesday, August 29, 2001 12:35 Subject: [Algorithms] Bounding sphere of spheres > Is there any stupidly fast method of finding the bounding sphere of several > spheres? Ashamed to admit it, I first find the bounding box and then the > sphere from the box centre. Surely there are better ways. I'm not overly > concerned with accuracy, slightly loose spheres would do fine if it's fast. > > Cheers, > Madoc > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > 
From: Peter Prade <prade@ph...>  20010829 10:15:13

Well here is a simple algo to calculate the smallest bounding sphere for 2 spheres: Suppose you have two Spheres at P1 and P2 with radii r1 and r2... the bounding sphere (at Position P with radius r) is then calculated as follows: Delta = P1P2; Distance = Delta.Length(); // where Length calculates the Length of a vector Direction = Delta*1/Distance; // normed Directionvector from P2 to P1 if(r1>=r2+Distance) // sphere 2 contained in sphere 1 { P = P1; r = r1; } else if(r2>=r1+Distance) // sphere 1 contained in sphere 2 { P = P2; r = r2; } else { P = (P1+Direction*r1 + P2Direction*r2)/2; // Position of Bounding Sphere r = (r1+r2+Distance)/2; } You should be able to extend that to more than 2 spheres just by iterating... Cheers, Peter Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of T.M. Evans Sent: Wednesday, August 29, 2001 10:36 AM To: gdalgorithmslist@... Subject: [Algorithms] Bounding sphere of spheres Is there any stupidly fast method of finding the bounding sphere of several spheres? Ashamed to admit it, I first find the bounding box and then the sphere from the box centre. Surely there are better ways. I'm not overly concerned with accuracy, slightly loose spheres would do fine if it's fast. 
From: Wayne Coles <wcoles@re...>  20010829 09:54:25

Oops, just reread your mail, this seems to be what you're doing already, apologies :) > Where Normalize() stores the vectors normalized direction > into the specified > vector and a vector * scalar operation multiplies each > component of the > vector by the scalar. > Probably not the greatest but should work.... > > > > Original Message > > From: T.M. Evans [mailto:tmadoc@...] > > Sent: 29 August 2001 09:36 > > To: gdalgorithmslist@... > > Subject: [Algorithms] Bounding sphere of spheres > > > > > > Is there any stupidly fast method of finding the bounding > > sphere of several > > spheres? Ashamed to admit it, I first find the bounding box > > and then the > > sphere from the box centre. Surely there are better ways. I'm > > not overly > > concerned with accuracy, slightly loose spheres would do fine > > if it's fast. > > > > Cheers, > > Madoc > > > > > > > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > > Virus scanned and cleared ok > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Virus scanned and cleared ok 
From: Wayne Coles <wcoles@re...>  20010829 09:12:37

Off the top of my head... float GetSphereSetRadius( Sphere *pSphere, const int nSpheres ) { float fRadius = 0.0f; for ( int iSphere = 0; iSphere < nSpheres; iSphere++, pSphere++ ) { Vector vectFar; pSphere>GetPosition().Normalize( vectFar ); vectFar *= pSphere>GetPosition().Magnitude() + pSphere>GetRadius(); if ( absf( vectFar.Magnitude() ) > fRadius ) fRadius = absf( vectFar.Magnitude() ); } return fRadius; } Where Normalize() stores the vectors normalized direction into the specified vector and a vector * scalar operation multiplies each component of the vector by the scalar. Probably not the greatest but should work.... > Original Message > From: T.M. Evans [mailto:tmadoc@...] > Sent: 29 August 2001 09:36 > To: gdalgorithmslist@... > Subject: [Algorithms] Bounding sphere of spheres > > > Is there any stupidly fast method of finding the bounding > sphere of several > spheres? Ashamed to admit it, I first find the bounding box > and then the > sphere from the box centre. Surely there are better ways. I'm > not overly > concerned with accuracy, slightly loose spheres would do fine > if it's fast. > > Cheers, > Madoc > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Virus scanned and cleared ok 
From: Antoine Bouthors <antoche@al...>  20010829 09:06:13

I guess you could use the barycentre of the centers, each balanced by the radius of its sphere, to compute the center of the bounding sphere. The the radius is the max( length(SphereCenter(i)  BSphereCenter) + Radius(i) )  Original Message  From: "T.M. Evans" <tmadoc@...> To: <gdalgorithmslist@...> Sent: Wednesday, August 29, 2001 10:35 AM Subject: [Algorithms] Bounding sphere of spheres > Is there any stupidly fast method of finding the bounding sphere of several > spheres? Ashamed to admit it, I first find the bounding box and then the > sphere from the box centre. Surely there are better ways. I'm not overly > concerned with accuracy, slightly loose spheres would do fine if it's fast. > > Cheers, > Madoc > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: T.M. Evans <tmadoc@ti...>  20010829 08:33:59

Is there any stupidly fast method of finding the bounding sphere of several spheres? Ashamed to admit it, I first find the bounding box and then the sphere from the box centre. Surely there are better ways. I'm not overly concerned with accuracy, slightly loose spheres would do fine if it's fast. Cheers, Madoc 