On 10/20/19 1:18 PM, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscape net> wrote:
>
>> Well, I think I found an issue with the way that the angle is calculated for the
>> radial pattern.
>
> I had it in the back of my mind to mention the effect of phase, but forgot.
> The equations also seem to botch the phase adjustment as well.
> I noticed this when I realized I could probably use phase to rotate the color
> map instead of applying the unmodified pigment to the object and then rotating
> around the origin.
>
> I _think_ I got to the point where I fixed this as well, but it's all worth a
> thorough double and triple checking.
>
> FYI.
>
I think I have a fix in hand. Further that the problem with phase was
rooted in the base radial problem affecting non-integer frequencies.
Internally phase is an adder applied after the frequency multiplication.
See attached. Upper left is your f=360/270 as the new code renders the
breaks in continuity (ramp_wave).
Upper right f=360/270 phase 1/4. Lower left f=4. Lower right f=4 phase 1/4.
Done a fair bit of testing and looking OK to me. It will be a while
before I get a branch out as busy with real life until the middle of
next week. First thought about a branch for just this change, but it's
getting to where I'm carrying too many off master. I'm going to roll
this change into a branch for a set of changes around functions and
patterns I want including this update. I plan opening a more general
github issue covering everything in the set of changes too.
Bill P.
Post a reply to this message
Attachments:
Download 'radialfix_wphase.png' (197 KB)
Preview of image 'radialfix_wphase.png'
|
