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