"Bill Pragnell" <bil### [at] hotmailcom> wrote:

> So I'm curious to know what you've done here - are you aiming for simply a
> tileable version of the crackle pattern? Can this also be colored on a per-cell
> basis like my object-based version, or is it just the tiling you're after?
>
> I'd love to see the code once it's in a fit state :)

1.  The original, long-standing, and long-desired, and often requested goal was
to have a user-defined set of cell vertices.

2.  My personal long-standing goal was to understand how to create a Voronoi
pattern from scratch.

3.  I have demonstrated that tileable Voronoi is possible, and of course, native
built-in POV-Ray tileable crackle {} is supported, but easily made even if it
wasn't.

4.  What you're currently looking at is a full, user-defined cell vertice
Voronoi pattern, that is infinitely tileable, and able to be colored on a
per-cell basis by a user-defined array.

Tdg and jr have commented that "the math" behind this is a mystery, and beyond
them.   Not so, as "the math", what little there is, is minimal, and well within
their grasp, as most of it is, or can be, handled by POV-Ray.

I was very pleased with my long-overdue understanding of how to generate a
Voronoi pattern from first principles.  You and I agreed that the scalar output
of the function would "scrub" any information about the underlying cells, which
it does.

But as I was working the tiled version, the truth of the matter finally made
it's way through to me, and the solution is what I am calling POV-Ray CHEMistry.

The Coding-Human-Elementary Math interplay.

The Voronoi pattern is a "semiprocedural" pattern generated int he following
way:
You define the cell vertex points. [A, B, C, ....]
You calculate the distance between the current pixel (P) and each vertex point.
This amounts to vlength (A-P)
Then you just use a #for loop to shove all the distance calculations into a min
() statement to find the shortest distance / closest point.
You can use a select () function to limit the "reach" of this if you want...


So the output of the Voronoi function is a scalar distance.
It has no memory of where this number came from, and the math does not give us
any additional information.

But we are not limited to math, are we?
We are humans, and capable of recognizing patterns and properties, and reasoning
outside of the math.

And this is where are able to write the code to get the coordinates of the cell
vertex that generated the distance.

Pick any point in any of the Voronoi cells, and what do we know about it?
We know that that point is closer to that cell's vertex than any other cell
vertex - because this is the definition of the pattern.  So if I now (again)
calculate the distance between that pixel and every cell vertex, it will only
match a single Voronoi result in the original function.
How do we apply this Human understanding to the math and the code?
We compare the distance between the current pixel and each cell vertex to see if
they are equal.
This easily done by subtracting one from the other, since if they are equal,
then the result is zero.
So we can plug this into a select () statement, and if Distance-Voronoi is zero,
then --- return the Spline Index value for that vertex, otherwise, zero.

But we need to do this for ALL of the cell vertices, and so all we do is once
again use a #for loop to shove all those calculations into a sum () function.
All of the vertices that _aren't_ the closest one sum to zero, but the closest
one adds its Spline Index value to the result.

Now, we can define a parallel spline function that indexes RGB color values
instead of cell vertices.

And, instead of coloring the pixel based upon the grayscale value of the
distance function, we can just use the RGB value that the user assigns to that
cell vertex to color _every_ pixel that is closest to that cell vertex.

And there you go - full color, solid Voronoi, from SDL-only scalar-only POV-Ray
functions.

We can then use the distance function to multiply the rgb value to get colored
shading, and the index value to define other arrays for textures, finishes,
normals, etc.

To make this tile infinitely, we just restrict the vertices to the 0-1 range,
and use select () and abs () to make mod() behave nicely across the -, 0, +
transition.

I'll hopefully clean up some of the code this weekend, and add a full discussion
of this as a section to my Function Monograph that I started writing for folks
like Kenneth.

I'll have to take a look at why it's SO SLOW.   But other than that, I'd say
that future development would include a weighted Voronoi (which may be analogous
to POV-Ray's crackle form vector), a 3D version / expansion of the current
implementation, and also figuring out the best way to implement the Delaunay
triangulation - either from first principles, or by using the Voronoi as a
basis.
I'm thinking that a 3-pass Voronoi pattern would give the 3 closest cell
vertices, and then I can use triangle {} to show the pattern.


Also, maybe we can apply this POV-Ray CHEMistry to some past problems or new
projects to see how far we can push it.

Post a reply to this message

Attachments:
Download 'tileablevoronoitest.png' (96 KB)

Preview of image 'tileablevoronoitest.png'