Re: [boost] [geometry] area, length, centroid, behavior

Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2009-02-28 19:18:36

Hi,

> GIS is my work area, so I know it's huge, but it seems like you are
> trying to tackle GIS + generic geometry library.  I don't get the
> impression that game programmers, for example, will enjoy or use this
> library.  Polygons are not closed (and rarely used, only triangles
> are) in games, and cannot have holes, and any error checking to
> determine otherwise is wasteful.  Winding is handled by the rendering
> API, and is also rarely, if ever, checked since the model exporter
> will have enforced the correct winding.

Me and Barend discussed a bit about this, as I'm personally more
concerned about game programing than GIS. So I guess that until now,
my participation to the library has been influenced by this point of
view.

What you say is true about what the library currently *provides*
(GIS-oriented algorithms, even if polygons with holes can be used in
games contrary to what you say, to display 2D vectorial fonts for
instance). But it's false about the *potential* of the library, and
this has always been my main concern since the beginning.

I focused my efforts until now on the kernel because I think that the
different application domains (GIS, games or whatever) won't
necessarily share the same algorithms but can share the same kernel.
If an algorithm is to slow because it can handles polygons with holes
while game programmers use plain triangles, the key of the problem is
to know if the library has been designed generically enough to sort
that out. If mechanisms like tag dispatching and/or concept refinement
are present and designed so well that I can add a triangle concept,
take advantage of the algorithms already present for polygons, and
specialize the ones that deserve to be, there's no problem. We can do
that and game programmers will be happy with the library, like GIS
ones were happy with the stuff already present.

So the kernel is the key.

Right now Barend wants to write more algorithms, and those algorithms
are GIS-oriented since this is his domain. This doesn't remove
anything from the library. It can even improve the kernel: as Douglas
Gregor writes in http://tinyurl.com/cw3qk5, "concepts are neither
designed nor invented, they are discovered through the process of
lifting many algorithms within the same domain." So writing more and
more algorithms, even targeted toward one application domain, can only
give a chance to improve the kernel. Of course it would be good to
make the same in other domains as well, and as soon as I have more
time, I'll try to test the kernel against some more game-oriented
algorithms.

Now the question is: is a Boost.Geometry library meant to contain all
the stuff necessary for every application domain (which is basically
impossible)? Personally, my approach would rather be to have
Boost.Geometry proposing just a kernel and the most basic algorithms
like point arithmetics, dot and cross products, etc... and having
extensions for more precise application containing potentially a lot
of algorithms...

Regards
Bruno