
Tutorial for Wykobi – A C++ Computational Geometry Library - signa11
http://wykobi.com/tutorial.html
======
bsder
Anybody actually have an assessment if this library is actually _accurate_?

The problem with most computational geometry libraries is that they tend to be
1) riddled with bugs, 2) slow and 3) covered by stupid licenses.

The license is nice. So, how is the accuracy and speed?

~~~
plafl
What I remember from college, more than 10 years have passed, from using
MicroStation and SolidEdge is that even professional design packages will
accumulate some errors. Actually you could build the same piece in several
different ways and some ways were more precise than others. My understanding
is that all operations are carried numerically and the only way that would
prevent accumulation of errors would be to perform them symbolically and solve
them numerically just at the end but I suppose that would be extremely
inefficient. I wonder if someone knows about any book or software library that
follows the later approach since I find the subject quite interesting.

~~~
alkonaut
So long as you are using floating point, most bets are off. What you can do
with FP is use _exact predicates_ which are always correct. That might, for
example tell you if two lines intersect, or if a point is inside/outside a
polygon without precision issues.

The problem with that is that you will soon want to _construct_ geometrical
entities. For example, if you intersect lines that have their ends on integer
coordinates you can't represent the intersection on integers (You will need
rationals, in that case). The same applies to floating point - two line
segments with floating point coordinates will not have their intersection
representable in floating point.

So for proper robustness in all situations you need "exact predicates and
exact constructions". A middle ground is "exact predicates and inexact
constructions". These modes are different kernels usable in e.g. CGAL.
[http://doc.cgal.org/latest/Kernel_23/group__kernel__predef.h...](http://doc.cgal.org/latest/Kernel_23/group__kernel__predef.html)

Even something seemingly simple such as saying "is point C to the left or
right of the line A->B" is very hard in floating point. It's possible without
too much sweat to use kind of series expansion where the length of the
expansion depends on the precision needed (you only go as far as you need to
answer the predicate, so often only 2-3 terms)
[https://www.cs.cmu.edu/~quake/robust.html](https://www.cs.cmu.edu/~quake/robust.html)

~~~
deadsy
>Even something seemingly simple such as saying "is point C to the left or
right of the line A->B" is very hard in floating point.

Is it? ie - construct a normal and take a dot product. That'll work the vast
majority of the time. Near the line you'll start running into the FP precision
limits. With 64 (...or even 32) bit floats that sort of distance is likely way
smaller than anything that represents a practical distance, so just call it
and say you are on the line. Of late I've been messing about with problems of
this nature and I can't say it's been all that difficult.
[https://github.com/deadsy/sdfx](https://github.com/deadsy/sdfx)

~~~
alkonaut
It comes back to bite you in a hurry. You don't need arbitrary precision to
represent arbitrarily small things but to not have algorithms break down.
Simple things like "is p inside the polygon" changes from true to false by
moving both point and polygon 1 unit to the right. See under the heading
"geometric predicates can FAIL" here
[http://groups.csail.mit.edu/graphics/classes/6.838/S98/meeti...](http://groups.csail.mit.edu/graphics/classes/6.838/S98/meetings/m12/pred/m12.html)

You are right that this happens only in edge cases. But you don't want that in
a cad program if you have anything doing e.g point-in-polygon, triangulation
or other such algorithms.

I know from experience that you really should bake this into the very
foundation of a cad package (if you see 2003 me, let him know)

~~~
willangley
The link didn't work when I tried it. I found "Robust Predicates and
Degeneracy" with a search:
[http://groups.csail.mit.edu/graphics/classes/6.838/S98/meeti...](http://groups.csail.mit.edu/graphics/classes/6.838/S98/meetings/m12/pred/m12.html)

~~~
alkonaut
Thanks, not sure why my iOS clipboard pasted a link I copied a week ago...
(corrected the link now)

------
Const-me
Another one, with more focus on 3D, boost license:

[https://www.geometrictools.com/](https://www.geometrictools.com/)

------
wmu
Both the tutorial and the library are nice. I never heard of Wykobi, and it
seems that the library is pretty rich.

------
coldcode
There are a lot of these apparently. I wonder why would a CPU implementation
make sense today vs a GPU one?

~~~
Const-me
Some things are not parallel enough. GPUs don’t feature thousands of
independent cores, instead they have group of cores executing same
instructions on different data, in lockstep. Some algorithms, e.g. shading
those triangles or raytracing or teaching neural networks, work awesome on
GPUs. Other are very tricky to port to that model.

Other things are not suitable for GPUs performance wise. For example, if you
have octree data structure and you query a lot, a CPU will perform better,
because cache hierarchy (on CPU, the top level[s] of the tree will be in L1,
the levels below in L2, etc., GPUs don’t have that), and because branch
prediction.

Finally, not everything is computation bound. If your CPU code is fast enough
to saturate IO bandwidth, be it HDD or network, you’re fine unless you have a
million of servers. If you have a million of them, GPUs might still be worse
they because might be more power efficient slightly decreasing your huge
electricity bills.

------
kelvin0
I am tempted to start a project to wrap this to be usable in Python. Very nice
lib.

------
mrcactu5
these tutorials read like a computational geometry textbook. I have gotten
stuck even on simple algorithms like the intersection of two lines. at least
in the beginning it may be hard to compute bugs

------
simooooo
Are there any libraries like this for JavaScript?

~~~
vespakoen
I guess d3
([https://github.com/d3/d3/blob/master/API.md](https://github.com/d3/d3/blob/master/API.md))
can handle most of these things.

Others you can check out:

\- [http://turfjs.org](http://turfjs.org)

\- [https://two.js.org](https://two.js.org)

\- [http://paperjs.org](http://paperjs.org) (especially "PaperScript" which
does some magic to allow adding / multiplying etc. vectors if that's what
you're after)

Also worth noting is that for most "computations" there is a likely a package
available on npm

------
mayoff
To clarify, this is a tutorial on how to use a C++ computational geometry
library named Wykobi. It is not an introduction to computational geometry or a
tutorial on how to implement computational geometry algorithms.

~~~
drifkin
For an introduction to computational geometry in general, I've enjoyed these
lecture notes from Leonidas Guibas [1]. There are some more specific class
notes at [2].

[1]
[http://graphics.stanford.edu/courses/cs268-16-fall/Notes/tor...](http://graphics.stanford.edu/courses/cs268-16-fall/Notes/torino.pdf)

[2]
[http://graphics.stanford.edu/courses/cs268-16-fall/notes.htm...](http://graphics.stanford.edu/courses/cs268-16-fall/notes.html)

