On 10/17/20 10:49 PM, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>> I'd guess there isn't much use in translating the non-working normal.cpp
>> quilted code so below is an my initial attempt at a fix for surfaces
>> perpendicular to the x, y and z axis. This updated code passes most of
>> my test cases...Whether this is what we want for a
>> best quilted fix - I don't know!
> 
> The majority of these look quite good, in my opinion, except for odd-looking -H-
> (I think one of its control points is negative.) Its inverted(?) pillow look is
> kind of hard to discern, though. It would be interesting to see it with a higher
> bump value.
> 

I've attached an hhh.png image with a bump_size of 1 instead of the 
default 0.5. The corners are raised relative to the middle parts. The 
apparent offset in each cube is due two lights of different colors and 
shading due light position.

---
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.

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).

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...)

Attached is a second image quiltedOptionTwo.png. The left set of 9 is 
the same A to I set. Here it's what users would see at the unit faces 
with the existing implementation (ignoring the noise issue). The offset 
is 0.5 for these. In the right set of 9, I've used an offset of -1.0. 
Many of the faces invert (inside of the pillow) and the results are more 
pillow like.

Is this a better way to go for a fix?

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.

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.

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.

Bill P.

Post a reply to this message

Attachments:
Download 'hhh.png' (87 KB) Download 'quiltedoptiontwo.png' (343 KB)

Preview of image 'hhh.png'

Preview of image 'quiltedoptiontwo.png'