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

> I keep thrashing around on what to do fix wise with the true quilted
> normal pattern...
>
> One of the weird things with the existing implementation is the x,y,z
> coordinates in the unit cube are all, always used in a distance from
> unit cube center calculation. This meant the quilt_cubic function was
> getting an over all range of values from 0 to 0.867.

Yes.  None of the vector components ever exceeded +/-0.5, and so
sqrt( pow(x,2) + pow(y,2) + pow(z,2) ) =
sqrt (0.25 + 0.25 + 0.25) =
sqrt (0.75) =
0.866025404

However, you're omitting the fact that the end result of the calculations was
them multiplied by 1/(sqrt(3/4) = 1.154700538
and 0.866025404 * 1.154700538 = 1.0

> However, at any given face position in the unit cube the range of values
> fed to quilt_cubic was in fact a sub range of the 0 to 0.867 range. At
> the unit face it was 0.5 to 0.867 (values delta of 0.367). At face
> positions moving inward toward 0.0 the delta range moved and increased
> in size (to 0.707 on the floor).

Because at N = 0, one of the vector components was always 0, and so the equation
would then be
sqrt (0.25 + 0.25 + 0) =
sqrt (0.5) =
0.707106781

This is the reason why in my initial coding, I instead used a function
incorporating min(max( QX2(x), max(QY2(y), QZ2(z)) ), 0)
(the equation for an isosurface cube)

The idea of course being that such a method should give a constant 1.0 along the
entire surface of any given face.

> We could go a different way for a fix. One which implements the
> previous, unit cube centered, face results by default, but which now
> offers an offset keyword. The offset would let users slide a 0.367 delta
> value range around as fed to the quilt_cubic function. Sort of a left /
> right slider for the posted quilt_cubic curves. (Back to the function's
> curves having meaning...)

Not sure where that comes from:
(0.367....  0.160?   0.867-0.707?
0.866025404−0.707106781 = 0.158918623)


> This offset keyword would allow users having existing scenes at face
> positions not on the full unit cube to achieve a previous result (in
> conjunction with bump magnitude) - at least where it wasn't previously
> some corrupt, partly inverted result.

Since I got lost and I don't understand, this would be something different that
simply translating the pigment pattern by some amount would _not_ fix?

> Aside: The thrashing here gets back to an early question of Bald
> Eagle's. Why not calculate 0-1 face input values for a Bezier curve
> where the user specifies both end points in addition to the control
> points. It looks to me like this was closer to the form of the original
> internal equation; later simplified.

I'm still confused about a number of points, the most basic and direct is the
graphing of the internal quilted function results vs the documentation graphs.

> Today suppose, that form of 'quilted_cubic' would better be an inbuilt
> function. Users could do what ever they wanted with it. Maybe I'll play
> with that too. Could be done with a spline based function, but a limited
> inbuilt should be quite a bit faster.

Have not been able to invest the uninterrupted and focused time to see where the
interpretation of the quilted function went wrong, or any of that.

But with regard to using a bicubic spline, that is how I got my function to
exhibit the "inflection point" that the documentation graphs show (It's just a
flat tangent=0 point).  Actually having a function that allowed a true
inflection point would be interesting - then a tile could have a groove around
the edge, like some cutting boards do.

Post a reply to this message