Re: [boost] [Review] GGL review starts today, November 5th

Subject: Re: [boost] [Review] GGL review starts today, November 5th
From: Pierre Morcello (pmorcell-cppfrance_at_[hidden])
Date: 2009-11-17 18:50:38

I had already stated some comments on GGL. (I am from real-time 3D world, not GIS). Barend has given me links to examples of use of ggl in realtime. Now I am trying to use the proposed ggl and I got some suprises with some elements of the design (this is still not a review).

1/
I am evaluating for myself the 'extensibility of ggl for real-time 3D (le'ts write rt-3D)'. 
How do I represent points at the infinity? This is pretty basic stuff in rt-3D. For example a directionnal light is positionned at (0.0,1.0,0.0,0.0), using the homogeneous coordinate. 
Can it really be integrated in the ggl easily? Did I miss it in the documentation?
Intersection of polygons with infinite points is also pretty basic when you begin to work with volume shadow (please note that there is much better than volume shadow, and I use this just an example).
I just would like to make sure you thought to this kind of things and have considered them while designing the library. If you think there is no problem, this is fine with me.

2a/
from ggl intersection module documentation:
"intersection: calculate new geometry containing geometries A and B"
I think this definition is dangerous : looks too much like union.

2b/
The library seems to suppose the user already know the result of an intersection, which feels strange to me. But maybe that is because I do not know GIS too much and more 'school traditional' geometry.
For example, if I want to calculate a line-line intersection, I have to provide a template parameter for the output type that seems to me completely unknown when I am requesting the calculation :
line-line can be : nothing / a point / a line. So will we need to create a new function intersection (geometric_intersection<>), or does the template specialization of intersection_inserter allow to already write it correctly?
A triangle - triangle intersection can be nothing / a plane / a line /a triangle / a point / etc... Is the ggl extensivity strong enough for this use?
This is all about my current questions on the ggl extensivity.

Just a little thought about geometry and precision.
This library is seems much more oriented towards direct evaluation geometry than geometry (which is for example determining what is the volume of the intersection between a cube and a sphere of the same center, the result being expressed as a function of Pi ). So let's say this not too much about formal geometry (Since nobody spoke of formal geometry while there was such a deal about FP correctness, I think that it was easy to loose sight of it). 
On the same subject, some algorithms are also quite stable, theorically perfect, but these requirements are also not enough to give the desired results. Example is Monte Carlo approach for calculating a volume in a space of degree 100 (you will in reality never get the exact result, but this still allows to do good quick calculations). So the user of the library would in a perfect world have the ability to select a not-so-exact algorithm for his calculations. As a consequence, I think this is not good to try to provide an algorithm that fits every need, and hides too much to the user. It's better if the user can write its own or select one of the provided implementation / strategy. In that case, he is supposed to have a fair knowledge of the domain, or at least have read in the doc the recommanded usage of the provided algorithms. From what I have read, it seems it will be possible in ggl. As a consequence, I think that the precision issue is adressed
 correctly in ggl.

About ggl presentation
Somebody on the list spoke of his book about different kinds of geometrys (epipolar/projective geometry etc...). Thanks to him, the subject appears in its big wide, showing that many elements won't be cover at all before a while in ggl. As a consequence, I have 2 opposing propositions :
1/it might be interesting to restrain the library goal to it's current usage (let's say templated GIS library), in order to wider it after a while and some extensions? 
2/ if not, it looks to me mandatory to make very clear the current state (not complete about geometry, good for GIS, but also waiting for extension on subjects : rt3D, etc). This would allow the 'hypothetical future user' not to be depressed by not finding what he is looking for in a generic geometry library, but also give a clear plan what is the development strategy of the library and its 'versionning' goal. 

Best regards,

Pierre