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

Subject: Re: [boost] [Review] GGL review starts today, November 5th
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-11-19 08:32:34

Hi Pierre,

Thanks again for your interest. Herewith our answers.

> 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.
>   
Indeed, points with infinite coordinates (in polygons or any other 
geometry) are not supported right now. As usual, this would be a 2-step 
task:
- Defining a way to allow users to say whether a point coordinate is 
infinite. That can be done with a function in a traits class, that the 
user will have to specialize and define. Some of them will decide to 
have the information as a separate boolean in their coordinate type, 
others will decide to rely on a special value, etc... it's really up to 
the user.
- Taking the information into account in the algorithms themselves. 
Obviously this will be done progressively, so the documentation will 
have to state clearly which algorithms support infinity and which don't.

The infinity function should be defined as returning "false" by default. 
This way, with the help of the optimizer, branches that handle infinity 
in algorithms can be discarded at compile time.

All this sounds feasible without breaking anything existing. Would it 
fit your needs, and do you think it's a good approach in general?

> 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.
>   
A and B is the commonly accepted definition. We extended the 
documentation recently at the start of our review, as there were more 
questions on backgrounds, you can look at the page
http://geometrylibrary.geodan.nl/formal_review/sets.html
explaining intersections and unions in more detail.

> 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?
>   
Yes, specifying the output parameter means specifying the behaviour. If 
you've an output iterator of points, it will deliver zero or more 
points. If you want lines, you get lines. Please not that line-line is 
not yet supported.

> 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.
>   
If we say for intersection: R = A & B, all three parameters are 
tempated. The dispatch function can be fully specialized on all three 
cases to support all combinations.

> 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.
>   
Sure, thanks. Both implementation and coordinate type can be varied.

> 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. 
>   
We see your points. The current usage is (I think) somewhat broader than 
GIS, though it is heavily influenced by it. For example, polygon 
clipping is implemented as polygon/polygon and polygon/box, and you see 
that in many domains, in GIS but also in gaming.
As is on the example on the main page, small pieces of the library can 
help in GUI applications (such as Qt).

Regards, Barend