Hi,
I think the voronoi node in Cycles is rather limited and extending it via OSL is rather slow (because only available on CPU). I therefore coded up a patch for the node tha tworks on the GPU as well as the CPU and implements most functionality available in the BI node.
example F2 - F1 texture:
Details (and source code) on my blog, let me know what you think. Is this useful enough to let me try and get it included in the source?
Ohoho… that would be very nice addition :yes:
can’t test & don’t know how to build win-x64 flavor (am on 7)
if anyone will make it, gladly will take it for a spin, show why is needed and good for 
Much appreciated!!! This is one of the reasons why they need to implement some type of loop construct for cycles SVM. Way back I experimented with implementing voronoi just using regular nodes but unfortunately I ran out SVM stack space. Because voronoi requires loops, you have to unroll each iteration. The best I could do was 2 dimensions and that used about 183 - 210 of the 255 stack limit. Third dimension was out of the question. Also annoying is the fact that stack usage seems somewhat random when dealing with more complex node layouts, hence the bounce between 183 and 210.
Without the ability to express loops for the SVM, cycles procedural texturing is very very limited. Stuff that is even trivial in GLSL can’t be done in Cycles.
I would also like to see a detail parameter as well (so it more closely matches the noise and musgrave textures in functionality).
A good argument for committing this patch would be that the new patterns you can generate have very little overlap, if any with what you can do with the other texture nodes.
Submitted it today (T45797)
Added the Chebyshev metric as well. Let’s see how it gets along with the reviewers 
@SynaGl0w: a loop construct would be useful but also a pain to implement in svm. Maybe there isn’t much of a technical barrier but the lack of (architectural) documentation is. It is certainly interesting though and I will study it some more, but my personal interest at this point is to be able to implement more basic patterns and noise sources (think hexagon and gabor noise respectively) to enable texture creators to get their hands on more basic building blocks without having to resort to CPU only OSL nodes.
@Ace Dragon: I am not sure what you mean my ‘detail’ in the context of a voronoi (cell based) pattern. These patterns are not recursive so there is no adding more octaves or whatever like in fbm and the like. The generalized minkowski metric might be what you are looking for?
@everyone: if there are patterns/textures or nodes that you think are missing in Cycles (either compared to what is available in BI or in general) I am happy to have a look at it and see if it is feasible to implement them and get them committed. Note shaders though (atleast not at the moment, because those are different beasts altogether and I am not sure I am up to that at this point
Very nice! Any thoughts on doing this: http://www.iquilezles.org/www/articles/voronoilines/voronoilines.htm
Personally I think the best kind of stuff to implement as dedicated nodes is anything that would otherwise use up too much svm stack space if created with the current selection of nodes: Anything that requires loops/iterations, etc.
There are a few crazy procedural patterns on the first page of my sketchbook that were a bit nuts to do with nodes. Hexagons can be done much simpler than using the n-gon node group like I did, but I wanted the extra outputs/texture spaces/ids/distances/etc. If you want to look at them I’ll post the node versions I did. I have a custom build that displays svm stack usage in the node editor for the current shader that I could run some node implementations through to see which ones are most stack expensive. I need to go find the diff I used for it =/.
A dedicated fast noise texture would be awesome, similar to the countless GLSL ones or the random source used inside of the advanced noise nodes we already have such as voronoi. 3D coords go in: unfiltered, pure noise comes out.
Not sure if possible, but for existing noise types a seamless toggle would be awesome, so that internal sampling of texture coordinates wraps around, so as to allow the creation of procedural seamless materials.
this looks like bevel node from substance
3:00
dont know if this type of workflow is possible in cycles, or whats missing in node editor
@pachupp: most of it is feasible already I guess, but bevel nodes and slope blur need the either the neighbourhood or derivatives of a pixel, something we might explicitely calculate for some patterns but I don’t a general bevel node is feasible in Cycles svm (it is in OSL and als in the compositor because the latter can access neighbouring pixels).
Made a first step in creating a completely new hexagon texture for cycles. It’s fairly feature complete but I don’t want to spend too much time on it before I get feedback on my previous patch (for the Voronoi extension)
you can get similar result (bevel from voronoi with bunch of cycles nodes), will show you tomorow how
regards
hi, yesterday by happy accident i get interesting effect similiar to beveled voronoi but ist totaly fake 
That is indeed quite interesting! I like the straightlined edges, which with all the continuous noises are hard to get. This could be very useful for camouflage or maybe cityscapes in the distance. Thanks!
Maaaaaan. I waited for this voronoi options for years!. You are my hero! 
I got some ideas for procedural textures improvements (based on math, not noob wishes). Are you planing working on Cycles more or those nodes was all you wanted?
Smooth voronoi would be super nice.
http://iquilezles.org/www/articles/smoothvoronoi/smoothvoronoi.htm
@Monio: I’ll certainly work on it some more but whether I publish it depends on whether it gets accepted. Most interesting stuff can be done equally well in OSL though (albeit slower) so I come across some interesting stuff I might implement it in OSL first. Because the Blender devs are a bit reluctant to accept new nodes because of the work the are putting into splitting the kernel and because my node patch didn’t fit the output pattern of the other texture/pattern nodes, I made a simpler VoronoiCrackle node that produces just F2 - F1 (and the color) so it has just two outputs. I’ll make that one available as soon as I have created the patch file.
PS> that smooth voronoi seems real easy to implement
Yeah, I read that on Patch page. If I recall correctly nobody is working on CUDA Kernel split right now (or they didn’t committing). Who knows when they do it? Somewhere in 2016? Maybe 2017?
“The best is the enemy of the good”
Imho Voronoi Cracle should be in Cycles since implementation of current Voronoi. We have “magic” texture but doesn’t have one of most usefull procedurals. Essential stuff for someone who work on procedural shaders/textures. Your code will be beneficial to hundreds of people.
If they want to keep the output standard with the others you could always just add your distances to an enum in the node options just like the distance types. That way all the voronoi stuff is still in the same node, and the outputs of the node remain unchanged. So in one menu you have your distances (F1, F2, F2-F1, F3, Crackle, etc.) and in the other menu you have the distance types (euclidean, manhattan, chebychev, etc.)
Mockup:
Just a suggestion to keep the voronoi node with the same outputs we have now, but the addition of internal node options. The default value of said options would of course produces the same output as the node does now, ensuring nobody has their materials broken. You would think that would be satisfactory to the patch reviewers.
SynaGl0w solution is great. Simple and elegant. Best thing is we can still scroll trough all options without need for adding new node to graph.
