Addd jcv_diagram_generate_vertices to generate unique vertices of edges

[cyfung]

Functions added to generate a list of unique vertices and their corresponding edges.
jcv_diagram_generate_vertices - generate the vertices after the diagram is generated
jcv_diagram_get_vertices - get the list of vertices
jcv_diagram_get_next_vertex - go through the list and skip invalid vertex

Invalid vertex (due to merge of duplication) only happens on vertex with 4+ edges and depending on the site ordering. I have tested several times with 60000 input sites without a single duplicate vertex, I believe it is because of the site ordering prevented this, but I am not sure.

The generate function go through all the graphedges once and make use of the CCW ordering and edge pairs to find common vertex.

jcv_altered_edge is just jcv_edge, but used the space occupied by a,b,c attributes for storing pointer to vertices. There should be minimal or even no memory overhead added for jcv_generate_diagram.

[lundmark]

How much does this influence the time it takes to generate the diagram?

[JCash]

To be honest, I wouldn't put this directly inside the main header file.
Instead, I'd create a helper file (e.g jc_voronoi_util.h or similar) and then create some helper functions there instead.

E.g. I've been thinking along those lines to add support for delauney triangulation, by adding extra functions to traverse a generated voronoi diagram.

Is this a feature you need @lundmark ?

[lundmark]

@JCash It's not really a feature that's needed, it's more a nice-to-have since I'm already doing something similar as a post-process on the output.

[cyfung]

These methods have no performance impact on the original function, you can see nothing is changed to the original functions, except allocation of jcv_edge.

However this is not a complete separate helper function, just because the aim of these methods is to avoid extra memory allocation by reusing the existing memory already allocated in the process, thus depending on the structure of jcv_edge.

As long as jcv_real is the same size is greater than or equal to the size of a pointer, the original function performs 100% the same. If size of a pointer is larger than jcv_edge, the impact would be extra space allocated, which is equal to 3 times the difference of the size of a pointer and jcv_edge.

Actually I am not sure if there is a system where jcv_real would be smaller than a pointer would be.

[lundmark]

Unfortunately I'm now seeing that we're getting these issues because of floating point precision errors. We get the same voronoi point positioned on two sides of a rounding causing them to be evaluated as separate points. So for example we would get 1.9999999 and 2.000000 and they're the same point in the actual jcv-diagram. So I'm going to apply this patch locally to us and see how that works and if it solves our problem.

[pjsdev]

Hi all, just started using this lib and it’s easily the most robust generator I’ve found. (Tried 3 others). Just commenting here to say Delaunay Triangulation would be great. @JCash, would you like me to put in a feature request?

[lundmark]

@cyfung I've encountered a situation where the resulting edges have vertices which aren't outputted by the jcv_diagram_get_vertices()-function. I've attached the points used to generate them. The first edge (1943.36743, 0.000000000 -> 1940.54077, 13.5084267) doesn't seem to have the first vertex generated?

failed_voronoi_points.txt

[lundmark]

Oh I forgot, it's limited by a rect of 0,0 -> 2048, 2048, maybe that's causing it?