Where do you access the points that are used to draw textures in nodes?

[TotalBSdf]

This thread prompted me to explore more general blender ideas Control Voronoi distribution (cell size) with second texture
where the goal is to control the jittering of voronoi cells via another image. I tied playing around with all kinds of mapping and xyz setups but none of them quite did the trick, so it occurred to be that native blender nodes might not even have the capacity to let one edit the draw points of a texture.

Hence me coming here and asking: where do I find an option to modify the draw points that control procedural textures? Is this a script node I need to add separately to control their jittering via the shading of another texture?

[SterlingRoth]

The built in voronoi node has no control over point distribution. There are .OSL scripts for editable voronoi point locations though.

[TotalBSdf]

You mean it’s just a flawed design? There’s no way to modify the node and you’d have to make a completely new one from scratch? Can’t you just copy and paste whatever script comprises the node and add some bit of code that indexes the locations of each point and then modifies those locations?

[SterlingRoth]

It’s a limited design. The current node system doesn’t have a good way to transmit point data to the shader, so there isn’t currently a way to modify those points.

The good news is, as Blender is open source software, you absolutely can modify that node to take in those points somehow and recompile the program.

There are existing scripts out there that you can plug into the .osl node that will probably do what you want, and will probably be much easier than coding it in C and recompiling. Do some googling, or search around this forum for 'voronoi .osl script"

[TotalBSdf]

OSL node? But I didn’t enable OSL language, this is all in whatever the default language is, probably Python or C++ or something.

[SterlingRoth]

Here is what I am talking about:

When you enable Open Shading Language, you can use the script node in cycles CPU rendering. If you find an .osl script, you can copy paste that into the text editor, and load that text object into the script node.

Now, you have access to the code of the voronoi texture, and you can modify it as you see fit.

[TotalBSdf]

Thank you, I’ll give it a try.

[SterlingRoth]

Here’s a link to the osl script I copy pasted: https://github.com/varkenvarken/osl-shaders/blob/master/Voronoi.osl

[Secrop]

@TotalBSdf

You mean it’s just a flawed design?

No. It’s a “time saving” design!

When a procedural texture is called, it’s called only for a specific point (sample). This has the advantage of allowing parallel computing of multiple samples, but it creates a gap between each sample, as they don’t ‘communicate’ with each others.

Voronoi is an expensive calculation to be executed in this kind of paralllel environment, and that’s why our ‘Voronoi’ texture uses the ‘Worley’ algorithm (by Steven Worley), and not a true Voronoi calculation.

The big problem of a true Voronoi procedural, is that for each sample, we need to loop over all points
in its vicinity to calculate the minimum distance to the sampling coordinate (and this lookup must be done for every sample!).

This is not suitable for ‘realtime’/parallel computing, as it might happen that the closest cell point might well be far away from the sampling point, which requires lots of calls to the featured points list.

On the other hand, the Worley Noise is simpler. It uses a grid of 27 cells (3x3x3 in the 3D/4D version) around the sampling point, and all samples perform the same operation! Its calculation is pretty straigth forward, and also easy to implement in parallel computing.

As SterlingRoth said, a true Voronoi can be implemented in OSL, but I can tell you that is quite expensive on its own. Even with a good lookup structure for your point data, it will be slow (exponentially slow, depending on the number of points in your list)!