Am 16.07.2016 um 18:24 schrieb Bald Eagle:

> Is there a good way to "get" such a matrix of 3D points from patterns in
> POV-Ray?  I don't quite understand how the infinite patterns for pigments are
> generated, stored, and used internally.

For most patterns, the principle is quite simple: To compute the pattern
value at a particular point in space, a pattern-specific algorithm takes
the coordinates of the points, does some mathematical operations on
them, and spits out a result. So in essence, each pattern is a
mathematical formula.

Where (pseudo-) randomness is involved, that's usually based on Perlin
noise (or a similar mechanism). In contrast to a classic sequential
pseudo-random number generator, where you need to pull the values in a
particular sequence to reproduce the same results, this mechanism can
reproducibly compute a pseudo-random-ish value for any given point in 3D
space, without having to look at any other point in space.

It may be surprising at first to realize that, in theory, this approach
can also be used to implement a voroni pattern, provided you agree to
certain non-random properties in the "seed points" of the pattern:

- In POV-Ray's voroni pattern, if you subdivide 3D space into 1x1x1
cubes (aligned with the coordinate axes, and <0,0,0> coinciding with a
cube corner), there will be exactly one "seed point" in each such cube.

This allows to evaluate the voroni pattern for any given point as follows:

- Take the coordinates of the point in question.
- From these, compute integer corners of the 1x1x1 cube in question.
- From these integer coordinates, compute three pseudo-random-ish values
and use them as the "seed point" for this cube.
- Likewise, compute the "seed points" of nearby cubes that could,
depending on their position, affect the pattern result.
- From all the potentially relevant "seed point" coordinates, compute
the pattern value for the point in question.

Theoretically, this is all the "magic" in POV-Ray's crackle pattern. In
practice, POV-Ray implements a way to speed up computation, by
maintaining a cache of already-computed "seed points".

> It would be nice to be able to generate an array that was composed of points
> inside of a contained_by{} box by somehow sampling that space and storing any
> value that's 0, 1, 0.5 - whatever it would be.

An algorithm to systematically search for the cell centers within each
1x1x1 cube should be comparatively simple to implement:

- Use a crackle pattern with `form <1,0,0>` and `metric 2`, essentially
giving you the distance to the closest seed point.

- In most cases, the seed point closest to the center of the 1x1x1 cube
in question will be that cube's own seed point; in that case, finding
the seed point is just a matter of evaluating the pattern's values at
four well-chosen points close to the center, and from those values
computing the distance and direction of the seed point.

- Once you have computed the position of the seed point, verify that
it's inside the 1x1x1 cube and that the pattern evaluates to 0 there
(give or take a small margin of error).

- If that is not the case, some other seed point is closer to the center
than the cube's own and will have messed up your results; in that case,
you'll need to repeat the process at other regions of the cube; my guess
is that the centers of the octants would be the next best choices. It
might also be worth figuring out where that interfering seed point is,
and probing the 1x1x1 cube reasonably far from it.


Alternatively, you could try to re-implement POV-Ray's "seed point"
generation algorithm in SDL.

Post a reply to this message