Re: GSoC 2017 - Implement boolean operations on polygons

[Juan Pablo Carbajal]

On Mon, Mar 6, 2017 at 5:03 PM, Richard Crozier <address@hidden> wrote:
>
>
> On 04/03/17 23:13, Juan Pablo Carbajal wrote:
>>
>> On Sat, Mar 4, 2017 at 6:14 PM, PhilipNienhuis <address@hidden>
>> wrote:
>>>
>>> abhishek singla wrote
>>>>
>>>> My name is Abhishek Singla. I am interested in working on the idea
>>>> " Implement boolean operations on polygons".
>>>> I have knowledge of C++ and have also used octave as part of my
>>>> curriculum
>>>> in subject Numerical Mathematics.
>>>> I want to contribute to the idea as I think I possess the required skill
>>>> set for this. But I do not know how to start working on it.
>>>> I would highly appreciate if you could give me a brief procedure on how
>>>> to
>>>> get started on this idea.
>>>
>>>
>>> The description of this project needs to be adapted.
>>> Last year most of this has already been implemented (by Amr Keleg who did
>>> good work), but not yet integrated into the geometry or mapping package.
>>> To
>>> get that far several issues have to be solved:
>>>
>>> - Weeding out the Boost library dependency (comprising just include
>>> files).
>>> In the eyes of the involved package maintainers (who weren't involved as
>>> mentors) this is a ridiculously large library compared to the two or
>>> three
>>> functions that use it.
>>>
>>> - Polishing the existing code (a.o., error catching, input validation,
>>> etc).
>>>
>>> - Making the code independent of just one Boost version (currently 1.60).
>>>
>>> More info in the patch tracker, see patch #9000.
>>>
>>> I doubt if the above three together would qualify for a GSOC project.
>>>
>>> Philip
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://octave.1599824.n4.nabble.com/GSoC-2017-Implement-boolean-operations-on-polygons-tp4682161p4682164.html
>>> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
>>>
>> Hi,
>>
>> Exactly as Phillip said, the interaciont with boost has to be more clever.
>>
>> If you want to move in another direction, binding to CGAL[1] would be
>> another option. This will also allows us to have many other cool
>> functions for geometry.
>> Now this approach might be worth a new package maybe called CGAL.
>> Just to have it in mind. Choose wisely (hint: the boost cleaning up is
>> simpler).
>>
>> [1]: http://doc.cgal.org/latest/Boolean_set_operations_2/index.html
>>
>>
>
> I'd be wary of CGAL, I tried to create a wrapper, see here:
>
> https://github.com/crobarcro/mpolycsg
>
> but I found their algorithms to have limitations that made them of no use to
> me, see:
>
> http://cgal-discuss.949826.n4.nabble.com/CGAL-difference-on-Nef-polyhedron-produces-shape-with-duplicate-vertices-td4659760.html#a4659782
>
> That was a couple of years ago now, so maybe they fixed the issues, but
> their code is very complex and difficult to use, and far inferior to, say,
> OpenCASCADE which would be far more useful.
>
> There is a python interface to OpenCASCADE based on SWIG (see
> http://www.pythonocc.org/), there is also FreeCAD, which is a GUI program,
> but also a standalone python interface to OpenCASCADE geometry modelling
> routines and probably simpler to copy if anyone was interested.
>
> Richard
>
>
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>

Hi Richard,

I use CGAl without much troubles but I will check the links.

I think the philosophy is to provide bindings many bindings and let
the user choose which one they use. We will have low level functions
like
clipPolygons_boost.m, clipPolygons_cgal.m, clipPolygons_openCascade.m,
etc.., and then a front-end function clipPolygon.m which would provide
a friendly interface, input checking and maybe input formatting.

Since OpenCasecade has a python interface the decision to amke would
be whether we use it via the future octpy or we write another one
using the Octave C++ API.

As I said, since the boost interface is already in place, one could
improve that one as a low hanging fruit.

Regards,