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) 
S  M  T  W  T  F  S 





1

2
(2) 
3
(12) 
4
(16) 
5
(43) 
6
(22) 
7
(35) 
8
(4) 
9
(5) 
10
(6) 
11
(2) 
12
(17) 
13
(5) 
14
(8) 
15
(5) 
16
(10) 
17
(11) 
18
(6) 
19
(14) 
20
(1) 
21

22
(2) 
23
(8) 
24
(2) 
25
(1) 
26
(4) 
27
(31) 
28
(28) 
29
(1) 
30
(4) 
31
(12) 
From: Tom van Dijck <tom@mu...>  20040131 23:12:44

Uhm.... you just don't use it.... The preprocessing pipeline should strip most of the geometry to reduce vertex count. Otherwise, in case you really want to use it, you still have to do some preprocessing, to make sure each batch does not use indices outside the batch, and since batches are rather small, I think it is of no use to do so... But my guess is, that this is kinda offtopic by now, since we are going to discuss PS2 specifics, I guess we could better continue on the ps2newgroups, before Brian is kicking our butts..  Original Message  From: "Jani Kajala" <kajala@...> To: <gdalgorithmslist@...> Sent: Saturday, January 31, 2004 11:37 PM Subject: Re: [Algorithms] indexed face list efficiency > > VUs can use indices efficiently enough, as well as posttransform caching. > > The performance implications aren't exactly the same as on other hardware > > How do you handle the VU1 memory limit when using indexing? > > > Regards, > Jani > >  Original Message  > From: "Rok Erjavec" <rok@...> > To: <gdalgorithmslist@...> > Sent: Friday, January 09, 2004 11:08 AM > Subject: Re: [Algorithms] indexed face list efficiency > > > > > Until you start coding on PS2 though... the damn machine doesn't even > know > > > what indices are... > > VUs can use indices efficiently enough, as well as posttransform caching. > > The performance implications aren't exactly the same as on other hardware > > (ie. prelit or trivial shader geometry may actually run slower with > > indexing) but it's still usefull. > > > > > > >  > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 35 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Jamie Fowlston <jamief@qu...>  20040131 23:09:12

chop your model up :) jamie Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Jani Kajala Sent: 31 January 2004 22:37 To: gdalgorithmslist@... Subject: Re: [Algorithms] indexed face list efficiency > VUs can use indices efficiently enough, as well as posttransform caching. > The performance implications aren't exactly the same as on other hardware How do you handle the VU1 memory limit when using indexing? Regards, Jani  Original Message  From: "Rok Erjavec" <rok@...> To: <gdalgorithmslist@...> Sent: Friday, January 09, 2004 11:08 AM Subject: Re: [Algorithms] indexed face list efficiency > > Until you start coding on PS2 though... the damn machine doesn't even know > > what indices are... > VUs can use indices efficiently enough, as well as posttransform caching. > The performance implications aren't exactly the same as on other hardware > (ie. prelit or trivial shader geometry may actually run slower with > indexing) but it's still usefull. >  The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 35 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Jani Kajala <kajala@ga...>  20040131 22:37:48

> VUs can use indices efficiently enough, as well as posttransform caching. > The performance implications aren't exactly the same as on other hardware How do you handle the VU1 memory limit when using indexing? Regards, Jani  Original Message  From: "Rok Erjavec" <rok@...> To: <gdalgorithmslist@...> Sent: Friday, January 09, 2004 11:08 AM Subject: Re: [Algorithms] indexed face list efficiency > > Until you start coding on PS2 though... the damn machine doesn't even know > > what indices are... > VUs can use indices efficiently enough, as well as posttransform caching. > The performance implications aren't exactly the same as on other hardware > (ie. prelit or trivial shader geometry may actually run slower with > indexing) but it's still usefull. > 
From: Crosbie Fitch <crosbie@cy...>  20040131 21:22:42

How about tesselating a sphere and precomputing indices to bounding circles? Say your sphere is tesselated in regular polygons (bar peculiar tiles). You tabulate a list of all potential minimal bounding circles (for all permutations of tesselation pattern). Each polygon contains a list of indices to all circles that contain it. You then project your cones and wherever they cover or intersect with a tile, the whole tile is marked, and all indexed circles are rejected. What you are then left with is a list of virgin circles. If you've ordered them by size, it should be easy to find the largest. This is then your candidate minimal bounding circle. You can shrink this by the diameter of a tile, and create a rejection circle and reject all cones that fall within it. You could conduct this process iteratively on successively greater resolution tesselated spheres. Perhaps you map a peculiar tile to your cones' centroid (to eliminate it and its antipode from consideration  if the peculiarities are only at poles)? There may also be symmetry optimisations available. 
From: Kyle Wilson <kyle@ga...>  20040131 20:56:36

Stephan Rose wrote: > Ok here's the problem... > > Have an arbitrary polygon... > > Need to figure out a way to create a list of triangles out of this for the > video card to render...correctly if at all possible. :) I recommend Seidel's algorithm. You can find an implementation used in realtime graphics at: http://www.cs.unc.edu/~dm/CODE/GEM/chapter.html Delaunay triangulation would probably produce betterlooking results (fewer long, thin triangles), but be much slower. Regards, Kyle 
From: Jamie Fowlston <jamief@qu...>  20040131 20:37:49

googling for 'tessellate polygon' seems to turn up lots of relevant hits. Last time this discussion came round, lots of people pointed at OGL (e.g. http://www.sgi.com/software/opengl/glandx/xlib/subsubsection3_2_2_1.html). jamie Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Stephan Rose Sent: 31 January 2004 20:00 To: gdalgorithmslist@... Subject: [Algorithms] Polygon to triangles Ok here's the problem... Have an arbitrary polygon... It is 2D only... Can be convex... Can be concave... Can be self intersecting... (although I could live without this case, but it'd be nice if I can handle it) Need to figure out a way to create a list of triangles out of this for the video card to render...correctly if at all possible. :) I've been trying to google on this but so far have had no luck... So I thought I'd ask here..any ideas anyone? Thanks, Stephan  The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 35 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Stephan Rose <kermos@so...>  20040131 20:03:38

Ok here's the problem... Have an arbitrary polygon... It is 2D only... Can be convex... Can be concave... Can be self intersecting... (although I could live without this case, but it'd be nice if I can handle it) Need to figure out a way to create a list of triangles out of this for the video card to render...correctly if at all possible. :) I've been trying to google on this but so far have had no luck... So I thought I'd ask here..any ideas anyone? Thanks, Stephan 
From: Tom Forsyth <tom.forsyth@ee...>  20040131 11:20:47

I think it's O(n^3) actually! n for the first vector, n for the second, = then n to check if that plane is on the hull. But yes, interesting idea. I think it should be fairly straightforward = to be able to take two cones and find the two planes that bound them (the = cones themselves are "end caps"). So you don't need to test a whole bunch of vectors on the cones, which helps. > Using this plane, and the other vector, shoot a vector down=20 > the center.=20 > This is the direction of the new cone, and the angle can be derived=20 > from the plane and vector (V) the you found. Not sure this is true. In general, the planes that you're finding will = _not_ touch the final bounding cone, so they're not chords. But iffthey are on = the bounding _hull_, then that means the cones they are between will touch = the bounding cone. But once you know which the magic three cones are, I think you can = either do it analytically, just anneal the solution down to an acceptable one. Annealing at this stage is fine because you know which three it is, so = it's not an O(n^something)  it's just a vaguely constant cost. Someone also mentioned finding the frustum planes directly rather than making a final single bounding cone. That's definately an interesting idea. TomF. > Original Message > From: gdalgorithmslistadmin@...=20 > [mailto:gdalgorithmslistadmin@...] On=20 > Behalf Of John Pollard > Sent: 29 January 2004 04:48 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] Bounding cones. >=20 >=20 > Hmm, maybe this would work, but it may be a bit slow: >=20 > For each cone, build a list vectors that wrap around the cones origin=20 > (they would start at the origin, and travel along the cone=20 > hull). The=20 > number of vectors for each cone would be a function of each cones=20 > cos(theta). >=20 > Take two neighboring vectors (they should be neighbors, and belong to=20 > the same cone), and create a plane, where the normal should=20 > point away=20 > from all other vector end points. If all other vectors are=20 > on the back=20 > side of this plane, this is the correct plane, otherwise=20 > choose another=20 > two neighboring vectors until you find the correct plane. >=20 > If you don't find any planes that satisfy this, you can't solve it.=20 > Basically, we're looking for planes that are in the outer=20 > edge of the cones. >=20 > While checking if this was the correct plane, remember the=20 > vector that=20 > was the farthest from this plane, call the vector V, and the dist D. >=20 > Of all the planes that you find, choose the plane with the largest D. >=20 > Using this plane, and the other vector, shoot a vector down=20 > the center.=20 > This is the direction of the new cone, and the angle can be derived=20 > from the plane and vector (V) the you found. >=20 > Hope this makes sense. It's probably a tad bit slow, as it's=20 > O(n2), but=20 > could be a good starting point? >=20 > Tom Forsyth wrote: >=20 > > I have a bunch of circularcrosssection cones in 3D space,=20 > all originating > > from a single point (assume it's the origin). They are defined by a > > unitlength vector V (the central axis) and a cos(theta)=20 > term, where theta > > is half the base angle. All points P on the cone obey the equation > > (P.V)/P=3Dcos(theta). I've worked out the maths to take two=20 > cones and find > > the cone that tightly bounds both of them. So I can merge a=20 > bunch of cones > > by calling this on pairs of cones, but depending on the=20 > order you combine > > them you get a very loosefitting result, and the more=20 > cones you want to > > merge, the looser the result fits. > >=20 > > So I'm wondering if anyone knows a good way to find the=20 > bounding cone of a > > whole bunch of cones. If the cone angle goes over 180 then=20 > it's fine to > > return "don't know", so it doesn't need to handle crazy cases. > >=20 > > I'm using this to find frustums for shadowbuffers  each object is > > represented by a cone from the (point)light that bounds the=20 > mesh, and I want > > to find the frustum that bounds a collection of objects as=20 > tightly as > > possible. > >=20 > > I have a feeling this is a similar problem to finding good=20 > bounding spheres, > > but I don't know how to solve that particularly well=20 > either. It's also > > almost identical to the 2D version  finding bounding=20 > circles  but not > > quite because the circles are the projections of the cones=20 > on the surface of > > the unit sphere  you can't simply project them to a flat=20 > plane and solve > > the problem there because (a) which plane do you use? and=20 > (b) they're not > > circles when you project them, they're ellipses. > >=20 > > TomF. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >  > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 35 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > >=20 >=20 >=20 >=20 >  > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 35 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 
From: John Pollard <johnp@3d...>  20040131 04:40:02

Hmm, maybe this would work, but it may be a bit slow: For each cone, build a list vectors that wrap around the cones origin (they would start at the origin, and travel along the cone hull). The number of vectors for each cone would be a function of each cones cos(theta). Take two neighboring vectors (they should be neighbors, and belong to the same cone), and create a plane, where the normal should point away from all other vector end points. If all other vectors are on the back side of this plane, this is the correct plane, otherwise choose another two neighboring vectors until you find the correct plane. If you don't find any planes that satisfy this, you can't solve it. Basically, we're looking for planes that are in the outer edge of the cones. While checking if this was the correct plane, remember the vector that was the farthest from this plane, call the vector V, and the dist D. Of all the planes that you find, choose the plane with the largest D. Using this plane, and the other vector, shoot a vector down the center. This is the direction of the new cone, and the angle can be derived from the plane and vector (V) the you found. Hope this makes sense. It's probably a tad bit slow, as it's O(n2), but could be a good starting point? Tom Forsyth wrote: > I have a bunch of circularcrosssection cones in 3D space, all originating > from a single point (assume it's the origin). They are defined by a > unitlength vector V (the central axis) and a cos(theta) term, where theta > is half the base angle. All points P on the cone obey the equation > (P.V)/P=cos(theta). I've worked out the maths to take two cones and find > the cone that tightly bounds both of them. So I can merge a bunch of cones > by calling this on pairs of cones, but depending on the order you combine > them you get a very loosefitting result, and the more cones you want to > merge, the looser the result fits. > > So I'm wondering if anyone knows a good way to find the bounding cone of a > whole bunch of cones. If the cone angle goes over 180 then it's fine to > return "don't know", so it doesn't need to handle crazy cases. > > I'm using this to find frustums for shadowbuffers  each object is > represented by a cone from the (point)light that bounds the mesh, and I want > to find the frustum that bounds a collection of objects as tightly as > possible. > > I have a feeling this is a similar problem to finding good bounding spheres, > but I don't know how to solve that particularly well either. It's also > almost identical to the 2D version  finding bounding circles  but not > quite because the circles are the projections of the cones on the surface of > the unit sphere  you can't simply project them to a flat plane and solve > the problem there because (a) which plane do you use? and (b) they're not > circles when you project them, they're ellipses. > > TomF. > > > > > > >  > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 35 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > 
From: Jonathan Blow <jon@nu...>  20040131 04:36:47

> up. If that doesn't solve it, I may end up rewriting the normal map shader > we're using entirely (it was one of the Neb2default ones)  maybe there's a > bug in it, and it would be good experience anyways. To be clear, it's not a matter of a bug or not a bug. The ATI shader works fine, and I'm sure the normal map shader you are using works fine. The issue is that there are several different ways to do things, so the tools on both sides have to match. The best option for this is to thoroughly understand what the generation tool does so you can just write the shader yourself. Failing that, you could just find a matched set of tool and shader (I'm sure the ATI tool has one). Modeling the higherres mesh even higher isn't going to magically fix the problem; it's not that kind of problem. 
From: tweety <mitea@sy...>  20040131 04:14:24

Look, thank you for your answers, both on the list and off it, but this is getting a lot more offtopic than my initial post (which, as it's been said, is not so much offtopic). This last post is just a flame. Please, stop responding. Again, thank you.  Peace and love, Tweety mitea@...  tweety_04_01@... YahooID: tweety_04_01 Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Tom Plunket Sent: January 27, 2004 5:01 PM To: gdalgorithmslist@... Subject: Re: [Algorithms] Game engine question > > He's asking what algorithm he should use that is (a) object > > oriented, and (b) minimizes texture swaps. > > The answer is, there isn't one. Obviously. There is rarely one solution to a given problem. Indeed, there are MANY ways that one could do this. > Well, you could maybe concoct something that is really complex and > weird and you manage to convince yourself is objectoriented, but at > that point you've dug yourself into a bunch of silliness. One of the implicit requirements should have been "is not complex and weird". This doesn't seem too farfetched to me. > Objectoriented design assumes a certain organization of your control > and data hierarchy. But optimization nearly always involves > crosscuts of hierarchies like that. This really should speak more to "this is not the proper OO architecture" than "OO is not useful in this case." One who actually understands OO would know this. > So if the point of your algorithm is to be efficient, you will often > find that it clashes with an objectoriented design (or any other kind > of overly structured design, for that matter). Overengineering is a huge problem in general, but not one that OO either solves or exacerbates. Clearly if your data structures are laid out idiotically then you'll have performance issues, but there's no rule that says to be OO you must be slow and stupid. Let's say that OO says that objects are nouns and their methods are verbs. Let's say that objects know how to do everything that they need to do to get their job done. (These are both things that I feel are valuable ways to think, at some level.) We are not saying that the EnemyAi Render routine plots pixels on the screen. That is SO the opposite of OO that I can't even begin to explain where the problems are. That EnemyAi has a Render call doesn't even mean to imply that the object will be rendered on the screen right now. It could be deferred by whatever other mechanism (be it OO or not) that pools this stuff, does texture sorting, you name it. Back to the OP, there is no one algorithm. However, one needs to consider that there is a layer in between the game code and the render code, and that they are not running in lockstep. To state that this is impossible, unweildy, or otherwise silly to do is simply ignorant. Being ignorant is not, in itself, a problem. The problem comes up when people claim to be experts and their arguments are so ridiculously filled with holes and hyperbole that even a moderately experienced practitioner can sink them with ease. OO is a tool. Nothing more, nothing less. To state that OO is useless for some problems is as valueless as stating that OO is the appropriate solution for all problems. Let's consider actually exploring the possibilities before stating with certainty what it's useful for and what it's not, mmk? tom!  The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 35 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Crosbie Fitch <crosbie@cy...>  20040131 02:32:28

> From: Paul Du Bois > To paraphrase for your case, find the point in S(2) farthest away > from any of your cones Then, one could find the nearest three cones? As those will then be sufficient to define the bounding cone. Dunno if that helps tho. 