Voronoi Diagrams on the GPU
rykap.com
rykap.com
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:
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$
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
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.
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.
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.
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 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
is also available as the more memorable:
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
This version may still have artifacts when the points fall too close to a cell boundary.
Also this guy, maybe more so. (There seems to be a connection).
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.
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
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.