The example code on devtalk provides the same banding issues so to achieve the same look as the original example on devtalk does require running it through a colorramp or similar.

Maybe it would be better to implement the edge output as an additional feature instead e.g. Crackle Edge?

Also, seems that calculatenormal(p) is quite different to using sd->N in SVM. Is there anything equivalent in Cycles SVM?

I found another example by Inigo Quilez. The shadertoy code is under MIT license.

https://www.shadertoy.com/view/ldl3W8
http://www.iquilezles.org/www/articles/voronoilines/voronoilines.htm

Good find, that algorithm seems better.

In D3673#84028, @Charlie Jolly (charlie) wrote:

Maybe it would be better to implement the edge output as an additional feature instead e.g. Crackle Edge?

Yes, I think that would be better.

Also, seems that calculatenormal(p) is quite different to using sd->N in SVM. Is there anything equivalent in Cycles SVM?

You could take the cross product of dPdx and dPdy, I think that's what it ends up doing in OSL. But then the normal is no smooth and you get facetting. The algorithm you linked may not even require a normal so maybe it doesn't matter.

The new algorithm is 2D so it will have the same issues that the original algorithm was trying to solve. I'll spend some more time experimenting!

Tests using OSL.

It seems the original algorithm from devtalk is better for 3D coordinates.

Hornwitser algorithm (devtalk) [white] > Hornwitser (with minor adjustments) [yellow] > Quilez algorithm [orange]

The Hornwitser algorithm using calculatenormal(p) [yellow] and when using N [red].

This is not quite what I remembered it to be, so I guess I should say a few things about the algorithm.

The discontinuities near the center of the voxels, shown below, is caused by an aggressive optimization I did. Rather than calculating the plane distance to all 26 neighbors (which was too slow) I made it take the shortest distance to the 3 closest neighbors according to the normal distance metric. This doesn't work near the center, but for what I wanted it worked fine. This optimization should probably be taken out. Unfortunately this probably means having to repeat the nested for loop, as the cell the point is inside needs to be known in order to calculate the distance to a given edge, and any one of the 26 other cells may have the edge closest to it.

The thing about calculatenormal(P) is that in order to calculate the distance along the surface, the normal provided has to be with respect to the coordinate system P is in. P defaults to the generated texture coordinates which doesn't change with rotations but N does, which means the calculations get all wacky as soon as the object is rotated if N is used instead of calculatenormal(P). If you know a way to get the normals of the surface before any transforms/deforms were applied that would be a possible way to solve the banding issue. Either way a socket needs to be provided to override the calculated normal, otherwise it may not be possible to get the right result when overriding the position input.

Finally I've been thinking that getting the distance along the normal to the points (F1,F2,etc) might be useful as well. And likewise with getting the distance to the edge with the other distance metrics. Which makes me think calculating the distance along normal should be a distance metric and distance to edge should be a feature output.

PS: is it possible to change my username to hornwitser?

In this case, perhaps @Brecht Van Lommel (brecht) can provide more detail about the normal calculations and if an equivalent is available from Cycles.

@Julian Siversen (sivert3), is it worth living with the discontinuities if the most important outcome is the edge?

Not so fast. Distance along surface normal to edge as implemented here is a different operation than distance to edge in D5743 and cannot be replicated by the features added in that patch. The reason to do distance along surface normal is that you get consistent derivatives along the surface, the original devtalk past linked at the top shows an illustration of how distance along surface normal (left) approximately compares to distance to nearest edge (right).

@Julian Siversen (sivert3) I understand your reply but the new voronoi code is very different and this patch is no longer applicable. I might take a look at adding it to the 3D type but I’m also stuck without a Cycles equivalent of the OSL ‘calculatenormal(P)’ function.