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 :)
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.
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.
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.
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
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/
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.
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
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.
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.
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.
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.
60 comments
[ 2.9 ms ] story [ 53.5 ms ] threadhttps://en.wikipedia.org/wiki/Voronoi_diagram
In the post there's a demo on how to use the same algorithm that generates Voronoi diagrams to render 2D drop shadows with a spread radius.
You may also be interested in Alan Zucconi's article on Voronoi diagrams where he outlines a few use-cases in games: http://www.alanzucconi.com/2015/02/24/to-voronoi-and-beyond/...
[0] http://www-astro.physics.ox.ac.uk/~mxc/software/#binning
[1] http://wwwmpa.mpa-garching.mpg.de/~volker/arepo/
[2] http://www.tapir.caltech.edu/~phopkins/Site/GIZMO.html
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.
when generalized to line segments, voronoi diagrams can be used to efficiently compute offset contours.
Offsets are used for CNC operations, slicing 3d print models, robotic path planning etc.
Another technique for computing them on the GPU, not sure how related it is to OP's technique: http://www.iquilezles.org/www/articles/voronoilines/voronoil...
Edit: shadertoy link: https://www.shadertoy.com/view/ldl3W8
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.- I found this to be a good starting point for WebGL as a whole: https://webglfundamentals.org/
- This is a great resource for learning about GLSL and shaders (writing code that runs on the GPU): http://patriciogonzalezvivo.com/2015/thebookofshaders/
- 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/
https://github.com/stackgl/shader-school
https://github.com/stackgl/webgl-workshop
https://github.com/stackgl/learning-webgl-01
https://github.com/stackgl/learning-webgl-02
http://patriciogonzalezvivo.com/2015/thebookofshaders/
is also available as the more memorable:
http://thebookofshaders.com/
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:
http://parmanoir.com/distance/
Distance transforms are a special kind of (max, +) convolution, and have lots of interesting algebraic properties
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'd love to see more stuff like this on HN.
Chris Wellons has a great article on the method that you mention: http://nullprogram.com/blog/2014/06/01/
It's also mentioned in the OpenGL red book: http://www.glprogramming.com/red/chapter14.html#name19
https://vimeo.com/159319784
Also this guy, maybe more so. (There seems to be a connection).
https://vimeo.com/155733402
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 complexity is num pixels*num entities.
implementation here: https://github.com/nraynaud/webgcode/blob/gh-pages/webapp/sh...
I would gladly show the result here: http://nraynaud.github.io/webgcode/various_tests/test_vorono... but it looks like Chrome removed PathSegList that the SVG library was using internally
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.
http://www.glprogramming.com/red/chapter14.html#name19
I didn't quite get what you need the stencil buffer for in that technique.
(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.)
But what advantage does a two pass stencil technique have over just writing to the color buffer in the first pass?
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.
This version may still have artifacts when the points fall too close to a cell boundary.