Extending the Voronoi node in Cycles: a progress report

In a previous post I reported on a small project to extend the functionality of the voronoi noise node in Cycles. After some discussion with developers and users, I spent some time on it and the basic code is done.

Basically the Cycles Voronoi texture node will have all the functionality of its Blender Internal counterpart: you can choose different metrics (= ways to define what a distance is) including the manhattan and chebychev metrics and you can choose whether you want to closest neighbor, the 2nd closest (and 3rd, 4th) or the difference between the 2dn and the 1st closest (a.k.a. Voronoi Crackle). A sample is shown below:

The node has the same outputs as before and just has two extra buttons and an extra input socket (E, which controls the exponent of the Minkovski metric):

The node defaults to the old options and produces output that is pixel for pixel identical to the old output (with a distance metric of Distance squared). The downside of all this extra functionality is that it is slightly slower (because it now has to choose between different metrics and has to keep around more data). So currently I am checking if or where it makes sense to optimize the code some more. I don't want to complicate the code too much because that would make both maintaining and reviewing the code harder, so at this point it might be more sensible to let it be and accept a few percent penalty for now.

Small additions to the floor board generator add-on for Blender

The floor boards add-on most recently described in this article got a minor update: by request I added options to rotate and scale the generated uv-map. Although this might done in the uv image editor as well, any actions there would be overwritten when changing the floor boards mesh again with the add-on. Of course a uv map can be tweaked in the material just as well with a vector mapping node for example, so which method you prefer is a matter of taste. The defaults are such that it shouldn't break existing objects/materials.

Another option that is now visible is 'Keep materials'. This was on by default but not exposed in the options. You can now uncheck it if you like in which case any associated materials will be removed from the object. This is of questionable utility, but I'd rather not keep an option hidden.

The UV randomization drop down now offers a Packed option: instead of randomizing uvs it lets all the uv coordinates of planks start at (0,0) without altering the scale. This might come in handy when texturing planks with small and non tileable images. (It will look repetitive but that way it won't show seams)

I also fixed a rather embarrassing normal problem. Thank you maraCZ for pointing it out so clearly.

Known bugs

Under certain circumstances the generated mesh will contain doubled vertices. I think this is caused by Blenders boolean modifier. (To simplify the code we generate a pattern that is guaranteed to be big enough and then cut it to size with a boolean modifier). For now, if you see strange lighting artifacts, go to edit mode, select all and choose remove doubles. I will look into this later.


The code is a single file, available on GitHub.

How to add a new node to the Cycles source code

I created a page where I documented each file that needed to be changed or added to create the VoronoiCrackle node that I would like to get included in Blender. It documents what is what and contains a link to the actual patch. It is certainly not perfect but might serve as a good starting point for people how want to give it a try (and for myself as a cheat sheet because adding a node involves many, many files :-)
The page is listed in the pages widget on the top right of the blog or via this link.

Space Tree Pro: Hazel tree freebie

The hazel tree that was used in the promotional image I created for this article is now available for free. You can download it from here. The materials are Cycles ready.

It serves as an example of what can be created with my Space Tree Pro add-on for Blender (available on Blender Market). It can be used as is or (if you have the Space Tree Pro add-on) as a starting point for other trees. (It has all the Space Tree Pro settings stored as object attributes, which will be recognized by the add-on)

Hexagon shader texture for Blender Cycles on GPU and CPU

First stab at adding a hexagon pattern to Cycles that can be used on the GPU as well as the CPU and that is not based on OSL.

The image was created with the following noodle:

As you can see, the hexagon node provide both a color and two float outputs. The first is the distance squared to the centre of the hexagon, the second one the distance squared to the centre of the nearest neighbour. Having both output allows for the easy creation of an edge, as shown in the noodle.


The code follows the implementation of the OSL version closely and might be sub-optimal. My first steps will be to document my steps in creating a completely new node (because no less than 15(!) files needed to be changed or added to implement a single node. After that I want to optimize the code a bit and wait for feedback on my previous patch before submitting this one.

Voronoi noise with cyclic metrics, an experiment

While working on adding more functionality on voronoi nodes in OSL I was wondering if we could vary the metric in some interesting way. The result of one of those experiments is shown below:

The noodle used to generate this image looks like this:

Note the number 7 in de metric drop down.


The pattern looks decidedly different from other cell like patterns and depending on the value of E can be made to look like anything from x-ray diffraction pattern(? at E=28) to stylized models of atoms (E=2.6):

The code for this metric(*) is this:
length(d) + (1 + sin(e * length(d)))/2;
i.e. we basically add a sine component to the distance. If E is zero this metric reduces to a plain distance metric. (*) Note that this isn't a true metric in the mathematical sense as it does not satisfy the triangle inequality.


The code is a minor adaptation of my previous script and is available on GitHub.
If you would like to know more about programming OSL you might be interested in my book "Open Shading Language for Blender". More on the availability of this book and a sample can be found on this page.

Fast Voronoi F2F1 in Blender Cycles on GPU and CPU

The voronoi noise texture in Blender Cyles is rather limited: it is only based on the distance to the nearest point while many interesting patterns need the distance to the next nearest points as well (or the difference F2 - F1). Also there is no way to vary the distance metric, everything is based on the distances squared while for example so called manhattan metrics yield squarish patterns that can be quite useful.

I did submit the path for review just now, if you're interested you can follow its fate here.

All of this can be overcome by using Open Shading Language, but the Cycles OSL implementation is limited to the CPU and cannot benefit from a much faster GPU. I therefore decided to try and implement it in the Blender source code and that went rather well (but see my rants below):

As you can see I added a second value output to the Voronoi node that yields the distance to the next nearest neighbour and added a dropdown to select the distance metric. Currently I have implemented the distance, distance squared (the default), manhattan and chebychev metrics, I might add the generalized minkowsky metric as well. The images show the F2 - F1 noise for the distance squared and manhattan metrics respectively:

The code works on GPU and on CPU but I only tested it on 64bits Linux (Ubuntu 15.04 to be precise) although there is no reason to believe it will work differently on antoher OS.

Can I haz codez?

The diff to the Blender source code as of 8/8/2015 is for the time being available via DropBox. If there is enough positive feedback I will try to get the patch accepted for inclusion in the source code. Note that the diff shows also some changes to files that have nothing to do with the node itself, notably device_cuda.cpp, which i need to tweak because although I have a GTX970 (= SM_52 capable) card, I didn't upgrade my cuda drivers so i needed to hack the source to restrict the cuda compiler to sm_50. This is irrelevant to the patch itself.

Some remarks about the code: coding this was not all pleasure and that is an understatement. No less than 8 files needed to be changed to alter a single node type. That isn't a bad thing in itself but there is duplicated code, a lot of redundant constants defined in different places and I could find no decent documentation on the stack based virtual machine (svm) that is used by Cycles. It took me way longer to fathom the ins and outs of the code than it took to write the code itself and I am still not 100% certain that I did not miss something. Blender is a wonderful piece of software but it certainly would benefit from a set of decent architecture docs :-)