William F Pokorny <ano### [at] anonymousorg> wrote:

> 1) A subtle use of pattern{} is to wrap existing functions with it so
> you can use the inbuilt pattern modifiers as part of creating a derived
> function. For example, we can apply isosurface perturbations with
> warp{}s. In the posted image the rough texture comes from the
> application of a warp{} turbulence. A code excerpt is below.

This is actually a great tip!
I personally look for to hearing about more of these types of capabilities.

> As a bonus (especially in yuqk using its raw_wave modifier), the
> approach often leads to much lower isosurface gradients because the
> perturbation is done by the warp{}. The 'nested isosurface evaluation'
> space is smoother / cleaner as the solver sees it - despite the overall
> result.

I have been delving a little deeper into this topic of late, and i have to say
that anyone looking to understand isosurfaces and gradients would be well served
to read Inigo Quilez's articles on min, max, and other functions messing up
Signed Distance Functions (SDFs), since they abruptly change or truncate the
values.
Mike Williams had some excellent advice about calculating the derivative of the
function (if possible) to get an idea about the gradient.

I have also been repeatedly running into the work of Mark Gillespie lately
https://markjgillespie.com/

as well as the Hessian matrix

So my to do list with regard to Continuing Education grows ever longer.

> (Long on my todo list has been trying this kind of pattern enabled
> perturbation with parametric surfaces too. Should work, but...)

I would implore you to look at the parametric code once again should you get the
opportunity.
It seems rather odd that it is so slow, when it should be the easiest to
calculate and render. (Especially when we can render it faster in SDL using the
"approximation" macros.
Isosurfaces require searching the whole contained_by container at the level of
the user-defined accuracy and estimating where the roots of the functions equal
the threshold.
Parametrics by their very nature allow the exact calculation of where the
surface is!

> 2) Bald Eagle posted code using a pigment{} alternative to pattern{}
> wrap. Both wraps are useful depending on needs. However, if what you
> want is the inbuilt pattern's singular value and not a color vector, the
> pattern{} wrap is faster - and more accurate (color vectors internally
> are 32 bit floats).

I did it that way as more of a didactic exercise, since people seem to more
familiar with the color map method of doing things.   Plus it explicitly shows
the 0 and 1 values returned by the color map and allows the user to follow along
at home by experimenting with different color map values.  It's also not
"hidden" under the hood like the pattern keyword method, so I thought there
would be less confusion by omission doing it the color map way.

> 3) I used yuqk's f_round() inbuilt function here as an alternative to
> mod() to get multiple torus shapes from each FnTorusWarp() use.

The more I experiment with patterns in POV-Ray, the more I'm convinced that I
could eventually write an entire 'nother monograph on modular arithmetic and
different versions of the modulo function that handle values in slightly
different but significant ways.


> The pattern mechanism (and very often the inbuilt pattern specific code
> in alternate ways) clamp and/or wrap values to a 0-1 range for use with
> *maps though it is often not necessary(*). There are several secondary
> issues too at the pattern <-> function interface in the official code.
> It, pretty much, all leads to choppy value fields (high gradients) for
> the isosurface solver.

While trying to craft some illustrations for some new isosurface documentation,
I was annoyed by constantly having to grapple with value wrapping with an
endless list of one-off solutions / work-arounds.

Then, as usual, I got a Crazy Idea about a general solution, where we never have
to worry about what the domain of the function results are ever again.  It's
completely reversible too.

I spent the better part of my day Saturday working out a method for reliably
mapping -inf to +inf onto the 0 to 1 domain.
Works like a charm.
The distribution of the raw conversion values sucks, but that was what the rest
of the day was spent fiddling with.
I spent a lot of time relearning what I did with the Importance Sampling code
that I wrote, and then pursued another route that finally gave me an even,
regular spread of values from 0 to 1.

All of the above would be a valuable addition to our value-handling toolbox.

> (*) The *_map code in all recent versions of POV-Ray can handle
> arbitrary pattern return ranges.

Huh?

Whatchoo talkin' 'bout, Willis.  ?

- BW

Post a reply to this message