If you really wanted to do it with my system, which would not be a good 
idea, you'd need to overlap 4 copies of the pattern on every axis, so 16 for 
an image, with each component being adjusted to behave like a part in a 
cubic formula to create a nice curve through the surfaces.

My system just blends between 2 values, but to get a nice smooth slope you 
need to blend 4 using a much more complex formula.

-- 
Tek
http://evilsuperbrain.com


"Samuel Benge" <stb### [at] hotmailcom> wrote in message 
news:45f04c0e$1@news.povray.org...
> Tek wrote:
>> "Samuel Benge" <stb### [at] hotmailcom> wrote in message 
>> news:45eef8a7$1@news.povray.org...
>>I figured I should post it anyway.
>>
>> IMO the problem is it's only blending to the adjacent cell, and it always 
>> uses pov's cubic curve rather than trying to maintain a smooth gradient.
>
> Yes, I was hoping to control that with a poly_wave n statement after a 
> cubic_mapped pigment_pattern, but it didn't work out very well. The cubic 
> wave is still expressed in the same way, only shifted one way or another.
>
>> If I'm understanding correctly Vincent's technique was actually doing 
>> cubic interpolation, rather than just using cubic_wave (which isn't 
>> equivalent)...
>>
>> Of course I'm saying all this without checking anyone's source code, but 
>> since it's based on my blended cells I would expect it to create curved 
>> steps where there should be a smooth gradient, which would cause the 
>> problem you're seeing.
>>
>> Wow I explained that really badly!
>
> Maybe so, but I understand why there are steps. I don't like it, but at 
> least I have the newest version of MegaPOV now. It supports bi-cubic 
> interpolation for image maps :)
>
> ~Sam
>

Post a reply to this message