Nifty because it is distributed, works in any metric space where voronoi regions make sense (XOR and non-euclidian ones as a start!) and easy to make into an online algorithim that updates as nodes join and exit.
basically:
given a center point $center$
given a list of candidate points $candidate$
to output a list $peers$
sort $candidates$ by distance from $center$
remove the closest candidate and add to $peers$ (it will always be a delaunay peer)
for $c$ in candidates:
if any member of $peers$ is closer to $c$ than $center$ then reject $c$
else add $c$ to $peers$
essentially this generates most of a delaunay triangulation, and you can quickly find the voronoi generator of a given point by greedily traversing the resulting graph.
Essentially to get published you have to give away all the publishing rights for the work you submitted. I'd prefer open access journals, but the people who decide if I get my phd don't value those like I do.
The IEEE actually has a reasonable policy https://www.ieee.org/documents/author_faq.pdf(see section 2). Essentially authors are allowed to post the version
of the paper that they submitted for final publication.
I love Voronoi diagrams, and especially Centroidal Voronoi Tesselations. They relate to many natural phenomena such as honeycombs and soap bubbles. I used that as the basis for an art installation I did for Burning Man: http://www.flowandwonder.com.
There's a much faster O(n) method for doing Voronoi diagrams on the GPU by taking advantage of the depth buffer. It's so simple that it gives you one of those "why didn't I think of this earlier" moments. I learned it from the old school demoscene guys at work...
0. Set up orthographic projection
1. Enable depth testing
2. For each "seed" point, draw an "infinite" cone all the way from the near to the far clipping plane
3. Shade with solid colors.
That's it.
The depth testing will only leave fragments of the cone that the corresponding pixel is closest to. If you need better precision, draw the "cone" by making a full screen quad and use the fragment shader to set depth (gl_FragDepth) according to distance from seed point (or just use enough vertices in the cones).
If you change the circular cone to a rectangular-based pyramid shape, you'll get Voronoi-type diagrams but with a different metric (manhattan distance?). Turn the rectangle 45 degrees to make a diamond shaped base and you have yet another metric.
The stencil buffer provides a boolean mask for the regions you care about, making it easy to draw them in flat color with a subsequent pass. I can't see a way to do that easily with depth information only.
(Plus, it was traditional to combine 24-bit depth with 8-bit stencil in the same buffer, so stencil writes were basically free if you're writing depth anyway.)
Oh, I see what you mean. Good question. I suppose it might have been more efficient to avoid multiple colour buffer overdraws (since you're drawing a fullscreen quad for each seed point, albeit a depth-tested one). And you could render the depth+stencil buffer once then reuse it to highlight different regions, e.g. on mouseover.
But you're right, it doesn't sound massively compelling. And the traditional 24depth+8stencil buffer format would limit you to a maximum of 256 regions, which could easily cramp your style.
well, if you're doing that, then just use the distance function, at least you've got a perfectly circular cone, and you don't get tricked by the maximum distance of the cone.
edit: it still works in firefox, it extracts the voronoi diagram, the medial axis, then does a subtraction on the medial axis (internal offset of the original polygon), then a minimum threshold (mickey ears for pocketting in milling), then a reconstruction of the polygon from the altered medial axis.
Your pixel shader implementation is quite clean and simple. But the method I described doesn't rely on shaders at all, it uses the fixed function triangle rasterization and depth testing. It has different performance characteristics. That method is also of historical interest because it works (and is fast) also on pre-shader graphics accelerators.
This isn't actually a voronoi diagram, it is an (approximate) distance transform - though it is still pretty cool!
If you are working on a grid, there are lots of ways to compute distance transforms exactly. An exact and optimal serial algorithm which works for any metric is due to Meijster, and it runs in O(n) time in the number of pixels:
The linked paper specifically says "Jump Flooding in GPU with Applications to Voronoi Diagram and Distance Transform," so are you sure it's not both in this case?
To compute a voronoi diagram, you also need to reconstruct the boundary and topology of all the cells, which is not being done here. Also most algorithms for computing voronoi diagrams do not snap the vertices to integer lattice coordinates.
Any good resources for getting started with WebGL? I'm going to start transitioning a large amount of slow <canvas> drawing to WebGL, and I'd love any pointers for someone getting started without any experience in graphics and gaming (which seems to be the starting point most tutorials use).
- As a starting point for implementing the Jump Flood Algorithm (which is what I used to implement the Voronoi Diagram demos) I found it helpful to read Chris Wellon's articles on GPGPU programming. Here's the first one: http://nullprogram.com/blog/2014/06/10/
Ryan! Thanks for writing this post. I had messed around with Voronoi diagrams in Processing and D3 without really understanding the intricacies behind it. This is a great explanation of what's going on.
It's not particularly efficient, but probably the easiest way to draw Voronoi diagrams on the GPU doesn't require a shader at all. Instead, use an orthographic projection and draw cones for each vertex with the cone's apex at the vertex and its axis oriented into the screen. Then the GPU's z-buffer takes care of choosing which vertex is closes to the given pixel.
Yeah! It's a pretty big omission in my post that I don't talk about other methods of generating Voronoi diagrams, but I wanted to keep it relatively short.
It's point picking for ~svg, where we draw a wider region than the actual elements and just go with that. The goal is not having to precisley click on small objects in a big scene. This generates a reverse index for knowing which element each pixel fuzzily refers to, and if far, if better described as blankspace. So, just 1 step, and we can cover a huge scene :)
If you use a grid of regularly-spaced points, you end up with a pixelated/mosaic image. Here's a (sadly Flash based) tool for applying a quadrilateral/triangular/hexagonal mosaic effect to a photo: http://damienclarke.me/code/mosaic-maker
Ironically, it's not working on my desktop browser.
I'm getting "DEMO DISABLED. COULDN'T START WEBGL." on my Chrome on Windows 10 on Intel integrated graphics setup, literally the most common browser on the most common OS on the most common graphics stack.
I'm sorry that you're running into issues - I just got started with WebGL and I don't have a Windows machine to test on. I'd be interested to know if other WebGL demos work on your machine. Do you see a triangle and square when you visit this page? http://learningwebgl.com/lessons/lesson01/index.html
In astrophysics, voronoi tessellation is used for adaptively smoothing data to reach a desired signal-to-noise ratio while trying to preserve as much spatial/angular resolution as possible [0]. It is also used in numerical hydrodynamic simulations to dynamically construct the mesh of cells for the hydro calculations[1, 2].
A little bit non-standard, but I used them to generate a map of the nearest vehicle spawn points for the game DayZ: http://i.imgur.com/GryW1fz.jpg
In the attached map, the red dots indicate a place where a truck might spawn. The polygons show the places nearest each truck. If a player wants to obtain a truck to drive, this map shows them which direction to run.
This was more a proof of concept than anything else, and is sadly outdated. In any case, it never took into account the steepness of terrain, which influences player running speed.
One use is in AI path planning algorithms. When you have a continuous space with obstacles, you can discretize the space by constructing a Voronoi diagram where the nodes are at the maximal distance away from obstacles.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru...
draft here (because I can't give away the final version): https://github.com/BrendanBenshoof/pyVHASH/raw/master/Paper/...
Nifty because it is distributed, works in any metric space where voronoi regions make sense (XOR and non-euclidian ones as a start!) and easy to make into an online algorithim that updates as nodes join and exit.
basically:
essentially this generates most of a delaunay triangulation, and you can quickly find the voronoi generator of a given point by greedily traversing the resulting graph.