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

> I think you did. Looks too me like only integer frequency multipliers
> have ever worked with the radial pattern. Probably how most use the
> pattern, but wow.

Thanks.  It looked real to me, and it was confusing to try to see what was going
on and get the desired behaviour in my scene, so I had to emulate the pattern
with a function so I could manipulate it's behaviour and track down WHAT was
going on...

> Attached is an image where the top two rows use a +z orthogonal camera
> and the bottom row a perspective camera. Always looking at a thin z
> plane sheet displaced by the radial's returned values.

Very very nice.  That's a great visualization of what's going on.

> The pattern in the
> 270-360 angle range start in the value range 1.00 to 1.25 and those
> values must "come down" by one to create a continuous pattern 0-1.
>
> The means even at the default frequency of 1.0 the wave modification
> code is using fmod() to bring the 1.00 to 1.25 values down. Top row,
> right column.

Yes, that's what I stumbled across and noticed as well.
I still don't fully understand _exactly_ what's going on - not enough to
articulate and explain it - but I could reach out and feel it in the dark and
imagine a fix.

> Where I used 360/270 as you did, we
> expose the discontinuity on the right of the second row.

Indeed, I think it was just pure luck out of laziness picking a 90 deg arc and
then filling in with 270 so I didn't have to write another 2 or 3 lines of code.
  :D

> In the bottom row on the left a perspective camera view with frequency
> 1.0. On the right 360/270. What's interesting to me is where the
> original pattern is continuous, the 1.333 works. We corkscrew by -90*y
> degrees - but this exposes the discontinuity. The size of the
> discontinuity also not consistent relative to frequency - at 1.9 it's
> much smaller. Expect that sometimes tends to hide the problem as well.

Yes.  I figured that it must be somehow due to the fractional portion of the
frequency that triggers the step when [f]mod() is applied.  That's why
everything looked fine when integer frequencies were used.  I had to play around
with that 0.25 magic number as well to understand what it was for and what it's
overall effect was.  Maybe define a HalfPi or QuarterTau constant in the source
to use there, along with a comment.

I could use a nudge in implementing a reversal of the color map, so that it goes
in the opposite direction...

> We should fix this and reduce those huge 0.001 tolerances around x,z
> zero too. We've got a discontinuity around the y axis too for most of
> the rotation around y. I'll put it on my list to create a code branch
> fixing these issues - stealing from your suggested code.

Well what I did there was get rid of the whole tolerance altogether.
#declare Radial = function (XX, ZZ, F, P) {select (XX*ZZ,  FreqPhase
(XX,ZZ,F,P), 0, FreqPhase (XX,ZZ,F,P))}

Assuming that if one of the atan2 arguments was zero, the product would be too.
For the purposes of source, that will probably have to be modified a bit and
bracketed by sanity checks and other safety nets...

> Aside: Apologies to all for my writing yesterday. Far too much of my
> usual internal 'thought-storm' got to the page. Happened to bring up the
> original post and - "frustrating to recognition" - among others. Dang
> brain...

No apologies - the reasoning and speculating, and train of thought is every bit
as useful to learning about all of this as concrete snippets of code and
illustrative renders are.
I always learn a lot.  Thanks for confirming and addressing this.  :)

Bill W.

Post a reply to this message