The main 'cool' thing about this project is its visuals (& its computational geometry).

Having the README without screenshots is lame.

At the moment, this class does a lot of stuff; and seems to be responsible for everything from
handling mouse events, maintaining the current structures used by the algorithms, and state / input from the buttons / widgets of the UI.

Surely some of these responsibilities can be split out into other classes.

'naked' TODO, XXX comments are comments without a date, without an issue number.

These are probably small and sensible things to do which would improve the code.

e.g. commits
d0c6ff80892433c3c37eeefe2540ec2716387541
3483059b9024abd59962c7678a6e05430b09a9a4
0ccd51a972d290be31a9642a5ef3b01a5c8bc37e
change use of plain-old pointers, to make use of C++11 smart pointers.

While I'm not sure Delaunay algorithm is the quickest algorithm to begin with anyway,
the changes were made without considerations to performance (e.g. speed).
And I'd guess it's slower to use them.

What licence does this repo have?
& the licences of its dependencies?

Currently, it's unclear what the setup / build instructions are for Windows.

AppVeyor already has everything installed, so it's presumably somewhat easier to build.
(Travis runs on Linux/macOS; where it's easier to know the commands to run to install these things).

This may include looking at whatever C++ "package" solutions are available for Windows.

http://doc.qt.io/qt-5/stylesheet-reference.html

• Wasn't implemented (nor modified!) by the authors of this project
• Seems that "normally" the algorithm's getEdges returns with ... (start, a, b) where start has numbers.
  • In degenerate cases, the start of the VEdge will have Nan.
  • I guess our polygon-construction (using winged-edges and everything) assumes this isn't the case?
• In the main.cpp of the code using this implementation, the points generated are all doubles, up-to-10000 in x, y coordinate. Our values are integers, and much smaller range.
  • With that kindof input, the implementation frequently runs into cases with NaN values in its start VPoint.

I don't know if it's a matter of:

• just render these edges anyway (will still look 'nice'); and buggy polygon-construction(?)
• the algorithm suffers too badly in edge cases.

In any case; probably better to just get rid of it for now; maybe investigate using some implementation of Fortune's if it turns out the Delaunay one is just too slow.

This is a C++ project. It should use C++ style casts.
https://stackoverflow.com/questions/28002/regular-cast-vs-static-cast-vs-dynamic-cast

My understanding is that currently, the built executable assumes that e.g. OpenCV, Qt5, and other DLLs are available on the PATH.

This means that it's not easy to share the built artifact + run on a different machine.

windows.h pollutes the global namespace, so we can't use the name Polygon.

Our timing needs aren't super precise; simple C methods for getting differences in time suffice for our usage. (Which is mostly just debugging / showing time some step took).

The way the software can be used, is that it can show:

• The loaded image
• The 'find edges' computation from the image
• Gaussian blurs of the find-edges; and the subtraction of these (to get the Probability Distribution)
• The "stained glass" effect.

The original intention was to lay out the buttons in a way that it illustrated this process.
I don't think that's very clear.
I think radio buttons (and disabling/enabling them as makes sense) would be a better approach.

Parts of the project use raw pointers, and also e.g. Qt5 connections
which probably need to be cleaned up.

This project renders an image, and various vertices, lines, polygons
using OpenGL.

As noted in comments in the code, QGLWidget is deprecated; since Qt5.4, preferred is QOpenGLWidget:
http://doc.qt.io/qt-5/qopenglwidget.html

Further, try and have some kind of code coverage badge.

It's not that the code coverage needs to be high.
But I think a project-badge & ability to have code coverage is itself pretty neat. :-)
https://coveralls.io/

The problem is:
The VornoiCLI program is just a debugging toy. It's useful for "just running the algorithm" when the
algorithm is broken. (e.g. for when we used the bad impl. of Fortune's; or when using imprecise arithmetic for Delaunay).

All the same, it uses point generation code from the 'lib' target. -- It seems stupid to me that this would depend on the OpenCV library. However, this is because the point generation code includes this fancy "edge-detection probability distribution field", which uses OpenCV.

That's ... a bit messy.
The point generation should be split between the uniform-random (which doesn't need OpenCV) and the edge-detection PDF (which does).

It'd be better to have rainbow colours than what's there now.

This project's usage of http://blog.ivank.net/fortunes-algorithm-and-implementation.html
... doesn't seem to result in a "Voronoi Diagram".

I'm sure the original implementation is good enough for our purposes, though.

QTest allows for basic GUI testing.

http://doc.qt.io/qt-5/qtest-overview.html

It may be useful for checking that basic situations don't break the code?

Commits since 2013 had broken the build for Windows.

e.g. use of namespaced geometry::Polygon as Polygon conflicts with a function (macro?) from windows.h.
Also references to SOIL.h and other things like that.

Currently, the .travis.yml only checks that the project can be built,
not that the tests pass.

getPoint's signature is like (index, x&, y&).

We're using our own geometry::Point class now. There's really no good reason to use getPoint.

The project has two algorithms:

• Delaunay triangulation
• Fortune's Algorithm

The algorithms aren't well documented here. Without that domain knowledge, it's difficult to
make sense of how the code ought to be structured.

Either discuss (with diagrams?), or link to places which do explain/discuss.

Once the build works for Windows, it would be beneficial to set up the project
to be built on AppVeyor.

This is good project practice; would help ensure the build doesn't break unintentionally if maintained from Linux or macOS.

http://doc.qt.io/qt-5/osx-deployment.html
Although CMake can generate a .app bundle at the moment, I don't think it takes any steps to e.g. bundle this with the opencv, qt libraries.

Look into this.

Catch2 (see #10) allows for more concisely written unit tests, which makes things more readable/apparent than the transliteration of the GTests which I have now.

Since we're using Qt5 anyway, might as well use its threading capabilities.
https://doc.qt.io/qt-5.10/thread-basics.html

Currently:

• sprinkled throughout the code are some commented-out cout << ... statements.
• As well as some "stopwatch" timings.
• And there doesn't seem to be an easy way to grab the input points used / retry with these.
• Nor is it obvious how "far through" an algorithm is.

These kind of log remarks and timings may be useful for a Debug build, but not Release. :-)
(It'd be nice to compile-time enable things like this for a Debug build, and omit them in a Release build).

Haven't touched this in quite a while,
but building/running now segfaults the program. (Running on Arch Linux).

Steps to Reproduce

1. Run program; open an image.
2. Draw image.
3. Generate random points.
4. Segfaults when clicking "Compute Voronoi Diagram" or so.

Segfault happens in polypixel.cpp, findSomeColor3iv(), when accessing loadedImageData.

It seems to me that the Delaunay's dag-node's find leaf nodes with edge is more expensive than it needs to be.

The method does use an expensive computation: 'is point in tri'.

At the moment, the Delaunay triangulation code is slow because it's using precise arithmetic (with LongInt). I suspect this code could be 'quicker' if using int (or double).
-- Although I'm not sure what detriment a small error-in-precision would cause.

http://en.cppreference.com/w/cpp/language/type_alias

Prudent use of this would surely clean up the code.

Doesn't initially draw properly.
If window is resized, etc., image will draw.

Currently, there are unit tests for the structures used by the algorithms,
but no unit tests for the algorithms Delaunay Algorithm we use.

I don't expect the algorithms perform well in edge cases. But there ought to be unit tests for basic cases.

Since many of the unit tests are geometric, having e.g. SVG diagrams of these may be helpful.
https://www.draw.io/ seems a nice, convenient way to make illustrations for this.

Currently, the edges are just plain blue. The vertices are plain black.

The blue looks uninspiring against images.

The black isn't useful against the black-and-white find-edges / etc. renderings.

The Fortune's algorithm we use had some weird encoding issues.