On Fri, Mar 17, 2006 at 03:09:26PM -0300, rodolfo@rodsoft.org wrote:
On Fri, Mar 17, 2006 at 10:17:53AM -0700, Richard Newman wrote:
Is it reasonable to extend the logic to check for 3D shapes (i.e., spheres instead of circles, etc.)?
It certainly would be a reasonable strategy to get the 2D work you have into the library and treat 3D as a later extension.
Well, 3D is a whole different beast, and is not implemented yet :) What I have is the following (with my name convention, to be changed...):
geom_t is an abstract base class with basic functions like: - center -> return the center point of the geometry - box -> return a rectangle encompassing the whole geometry - area -> returns its area
It would be better to have a set of nonvirtual classes defining functions like this inline, and then have a template wrapper class to convert one of these into a descendant of the virtual class. This way, someone who wants to use a million spheres (e.g., for a sphere hierarchy), won't suffer from virtual function overhead.
then there's the primitive classes that inherits from geom_t: point_t -> a single point in the 2D space circle_t -> represented as a 2D point and a radius rectangle_t -> represented as two points, the upper left and lower right.
You should probably think carefully about which basic types to use here, especially in terms of small vectors types. I'm not sure if boost has a small vector type yet (I didn't see one in uBLAS), but if so it should definitely be used.
I'm planning to add polygon and triangle soon.
There are also operator>> and << to transfer from and to a stream, and free functions that returns intersections, unions, etc.
All coordinates are double. Maybe each primitive should be a template, like: point_t<double> is a point with double floating point coordinates, point_t<int> is with integer coordinates, etc.
Templatization of the float type is good, and again point_t should probably be a general purpose small vector type. Geoffrey