"Bald Eagle" <cre### [at] netscapenet> wrote:

> > William F Pokorny <ano### [at] anonymousorg> wrote:
> > This meant the quilt_cubic function was
> > getting an over all range of values from 0 to 0.867.

Yeah, you/I should play around with PREmultiplying that by 1.15....

The implementation seems to me to be a bit unneccesarily Byzantine, and I tried
to keep the original function - but simplify it by multiplying through, and
that's how I got my interpretation of the quilted function wrong.

Your fix is indeed correct.

The part that has (still) got me mystified now is calculating the INPUT to the
quilt_cubic function, as the value function I was using with floor and FLOOR
didn't seem to make any sense.   It should be a mirrored function across 0, no?

We discussed this and I think for this application
#declare FLOOR = function (T) {floor (abs(T))}
is the kind of thing that is intended.

So to keep it simple I just do
#declare ValueX = function (X) {abs(X)-floor(abs(X))-0.5}

Then when I run through the calculations stepwise, I get something smooth and
symmetric. (But holy cow - that quilt_cubic function...  :O )

Here are the graphs I got when I plotted the original quilted sub-functions in a
daisy-chained stepwise manner (range -0.5 to 0.5) compared with how I originally
did mine (range 0-1).

I _think_ it looks right, given the full black and never fully white values in
the original pattern, but I'm confused about the difference between my SDL
calculations and the full color function {quilted ....} plots I did.
Which means I might still not be evaluating this correctly.

Given that the function {quilted ....} just gives a sort of flattened U, I'm
wondering if there might not be a simpler way to achieve THAT shape, since I
think whatever the (unlabeled) graphs were trying to convey were misleading.

The only other thing I can think of is to use a correcting function - perhaps
that can be enabled with a flag, that way new scenes could use the new or the
old way,
or implemented separately: something like pigment {function {quilted} * function
{quilt_correct}} could be done, so that extant scenes wouldn't have to be
modified at all, but new scenes could add the additional correction in.

The idea is that since there is a variation between the center of an edge and a
corner, a compensating function could be applied to make the whole edge
(reasonably) constant.

It's ugly, but "backward compatibility" always is.

My vote is to come up with a nice clean simple easy-to-understand and document
function has has none of the current problems, looks good on a single unit cube
at a large size, jettison the old code, issue a deprecation warning or "this
version of quilted is a new experimental feature, replacing the original...."
type message, and go from there.
(how many people have actually used quilted in past scenes?)

Post a reply to this message

Attachments:
Download 'quilted.png' (110 KB)

Preview of image 'quilted.png'