
CGAL – Computational Geometry Algorithms Library - lobo_tuerto
https://www.cgal.org/
======
je42
libigl also has some wrappers around cgal.

------
ioquatix
This is used by OpenSCAD for building meshes from boolean operations. It's
awesome, but a bit slow if you do anything complex.

------
marcosscriven
It was a while ago now, but managed to get a Javascript build of this going
with Emscripten:
[https://github.com/marcosscriven/cgaljs](https://github.com/marcosscriven/cgaljs)

------
droelf
I've used CGAL extensively in the past and found the implemented algorithms to
be of fantastic quality. The major pain points for me were also the really
sub-par Python bindings. Which are actually worse now, since they've switched
over to SWIG from Boost.Python.

If anyone ever needs Python bindings for CGAL that make sense, check my little
pet project out:
[https://github.com/wolfv/pygal](https://github.com/wolfv/pygal) :)

------
abetusk
My experience with CGAL is that it's slow, clunky and very difficult to work
with. I understand that it's the 'gold standard' of libraries but for the
purpose I was using it for (2d polygon boolean operations, polygon
offsetting), I found ClipperLib [1] to be far superior in terms of ease of
use, stability and execution speed. There's even a JavaScript port of
ClipperLib [2]. I highly recommend ClipperLib to anyone that only needs simple
2d polygon manipulation.

[1]
[http://angusj.com/delphi/clipper.php](http://angusj.com/delphi/clipper.php)
[2]
[https://sourceforge.net/p/jsclipper/wiki/documentation/](https://sourceforge.net/p/jsclipper/wiki/documentation/)

~~~
geezerjay
> My experience with CGAL is that it's slow, clunky and very difficult to work
> with.

I can't comment on the slowness and clunkyness, but in my very limited
experience with CGAL I also felt it was needlessly difficult to work with.

Perhaps investing some work in the documentation would help shed this idea.

------
mrcactu5
Python bindings for CGAL -- no subsitute for reading through the C code (or
implementing your own crude algorithms)

[https://github.com/sciencectn/cgal-
bindings](https://github.com/sciencectn/cgal-bindings)

------
tschmidt
Is anyone working on Rust bindings?

~~~
marvy
I doubt it. The library seems very happy to exploit whatever C++ features are
available, especially templates, to the point where I wonder how easy it would
be to use from a language where templates are even slightly different compared
to how C++ does it. Could you port the STL to Rust? I don't know Rust, so I
can't answer that. But if not, then there's not much hope of CGAL bindings.

------
SOLAR_FIELDS
This is the golden standard for geometric libraries. If you are building a
geometric library and want to scale it up to enterprise levels you cannot do
better than starting from this. It's built by a consortium of universities who
have contributed many many years of research in computational geometry to its
codebase. It solves edge cases that GEOS/JTS have not come close to solving.

If you need something to just do calculations for display on a Leaflet map,
PostGIS/JTS/GEOS/Turf.js will do just fine. If you want to build something
that needs to be rock solid, lightning fast, and 100% accurate in all cases,
use this library.

~~~
quinnchr
Isn't CGAL a dependency for PostGIS? When would you choose to use CGAL
directly rather than something built on top of it (e.g. PostGIS or pgrouting)?

My use case is mostly for routing and I'm currently using a heavily modified
version of OSRM. If there's potential for even more speedup I'd appreciate any
resources ou can point me towards.

~~~
turboladen
You might be thinking of GDAL.

~~~
vetinari
CGAL too, in the form of SFCGAL, that implements simple features on top of
CGAL.

------
santaclaus
My experiences with CGAL:

1\. Everything under the sun is implemented!

2\. Horrible build system, giant dependency (worse than Boost here)... I wish
they had gone header only like Eigen or ViennaCL.

3\. Ugly license. Essentially a no-go everywhere I've worked, although still
fine for academic projects.

~~~
ska
How is dual licence ugly? It's not expensive for commercial use.

~~~
w0utert
It's quite expensive, especially if you only need one feature from one package
that depends on multiple other GPL packages (which is most of them).
Everything included we got quoted over $25K for a feature which was decidedly
non-trivial, but the cost was still well above the "let's license it instead
of re-implementing ourselves" threshold.

~~~
wiz21c
Considering

[http://www.cgal.org/exact.html](http://www.cgal.org/exact.html)

I dare to say that 25K is not that much; if you had to do it yourself, it'd be
probably very expensive (of course, I don't know how good you are :-) but you
see what I mean).

(and yes, I did 2 years of R&D on quad trees with polygon intersections and
"exact computation" is super tough to achieve, you need lots of testing)

~~~
w0utert
For the application we were considering and the algorithms we liked from CGAL,
exact computation wasn't really an issue. I agree 25K is peanuts if the choice
is between developing yourself from scratch or licensing something from CGAL.
But in our case the choice was between CGAL, using a simpler and possibly less
advanced/less accurate solution, or using an alternative LGPL package.
Especially considering the many dependencies most CGAL packages have on other
packages, the value proposition for just using a small part of the library for
a single algorithm quickly becomes a hard sell...

~~~
ris
> For the application we were considering and the algorithms we liked from
> CGAL, exact computation wasn't really an issue.

So it sounds more like you weren't trying to buy the right tool for the job.

