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 > 