POV-Ray : Newsgroups : povray.beta-test.binaries : Fixing longstanding function/pattern issues in v38. New raw_wave keyword. Server Time
28 Mar 2024 19:12:41 EDT (-0400)
  Fixing longstanding function/pattern issues in v38. New raw_wave keyword. (Message 1 to 7 of 7)  
From: William F Pokorny
Subject: Fixing longstanding function/pattern issues in v38. New raw_wave keyword.
Date: 19 Oct 2019 12:52:37
Message: <5dab3f55$1@news.povray.org>
In an earlier post to this newsgroup:

http://news.povray.org/povray.beta-test.binaries/thread/%3C5da5ba46%40news.povray.org%3E/

I started documenting longstanding bugs and issues with VM function and 
pattern interplay. I believe as many as possible should be fixed in the 
POV-Ray v3.8 release. Documenting these bugs/issues as I do my best to 
find and fix them in my personal version of POV-Ray.

---
The internal kWaveType_Raw waveType clipka introduced with the new 
potential(1) pattern should go the whole way and be available via a new 
'raw_wave' keyword.

It's frustrating to recognition the core developers implemented 
significant infrastructure which should make creating and manipulating 
functions and isosurfaces via the pattern mechanisms easy - except often 
it falls short.

Everything exists today to code and run:


//--- FnZZ used directly in an isosurface - attached image left column
#declare VarPlaneSheetThickness = 0.01;
#declare FnZ = function (x,y,z) { z-(VarPlaneSheetThickness/2.0) }
#declare FnZ_inv = function (x,y,z) {
     -(z)-(VarPlaneSheetThickness/2.0)
}
#declare FnZZ = function (x,y,z) { max(FnZ(x,y,z),FnZ_inv(x,y,z)) }

#declare VarPlaneSheetOffset = 0.8;
#declare FnZZOffset = function {
     pattern { function { FnZZ(x,y,z) }
   //raw_wave // Without middle column, with get intended result right.
     translate <0,0,VarPlaneSheetOffset>
     turbulence 0.1
     }
}
#declare IsoPlaneZOffset = isosurface {
     function { FnZZOffset(x,y,z) }
     contained_by {
         box { <-1,-1,-0.20+VarPlaneSheetOffset>,
         <1,1,0.20+VarPlaneSheetOffset> }
     }
     threshold 0
     accuracy 0.0005
     max_gradient 1.3
     max_trace 1
     pigment { color Indigo4 }
}

but the above code doesn't work though the developers enabled the 
overall mechanisms.

The raw_wave keyword bypasses the usual pattern 'wave' modification code 
- including the code below which makes manipulating functions with the 
remaining pattern modifiers difficult(2) and very confusing.

Today one has to understand in detail how ALL the pattern wave modifiers 
work and how to hack your functions to get past the issues to use the 
warp/turbulence capability. Oh, and to use any pattern modified function 
in with other functions. It's a huge pain. Anyway, the problem code for 
many functions(3) is:

     /* allow negative frequency */
     if(value < 0.0)
         value -= floor(value);


Bill P.

(1) - Aside. I have concerns with the potential pattern for blobs and 
isosurfaces as currently implemented for v3.8. Other than perhaps being 
complete in providing an isosurface potential pattern, it doesn't make 
much sense. Most anyone will just use the function into the isosurface 
directly. Further, the keywords added code added slows all isosurfaces.
Lastly, with both blobs and isosurfaces the internal 'raw_wave' is hard 
set on - preventing the use of the wave modifiers when they could be 
used.

(2) - In the scene file provided for the thread referenced at top, it's 
why this extra, but today, necessary code :

#declare Fn00f_Tiling11_3 = function {
     pattern { function { max(0,-Fn00e_Tiling11_3(x,y,z)) } }
}

Yes, the clamping hurts the gradient and to get something a little 
better I code:

#declare Fn00_Tiling11_3 = function (x,y,z) {
     0.001-Fn00f_Tiling11_3(x,y,z)
}

instead of:

#declare Fn00_Tiling11_3 = function (x,y,z) {
     -Fn00f_Tiling11_3(x,y,z)
}

for the final isosurface function.

(3) - I have in mind an additional wave modifier keyword - 
function_wave(?) - which bypasses only the problem code. Not yet worked 
on it in detail. Aiming to allow most (or all) the existing wave 
modifiers with it. Excepting of course the new raw_wave one which just 
bails on that code.


Post a reply to this message


Attachments:
Download 'raw_wavekeyword.png' (28 KB)

Preview of image 'raw_wavekeyword.png'
raw_wavekeyword.png


 

From: Bald Eagle
Subject: Re: Fixing longstanding function/pattern issues in v38. New raw_wave keywor=
Date: 19 Oct 2019 14:55:00
Message: <web.5dab5bcde43f3c684eec112d0@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> Today one has to understand in detail how ALL the pattern wave modifiers
> work and how to hack your functions to get past the issues to use the
> warp/turbulence capability. Oh, and to use any pattern modified function
> in with other functions. It's a huge pain. Anyway, the problem code for
> many functions(3) is:
>
>      /* allow negative frequency */
>      if(value < 0.0)
>          value -= floor(value);
>
>
> Bill P.

Ha!   I just pulled up the code in pattern.cpp this morning and was looking at
that exact section.

I thought perhaps there was some strange way that radial was implemented, but I
should have recalled from my other source patterns to SDL work that it's just
dirt simple.
And I did see the code for special handling of all the wave types, and given
that NPC just posted about the asteroid normal map, I thought maybe that might
solve my "scaling" woes.

Nothing yet - but it's something to play with.

I suppose I ought to somehow graph all of those out so that I have a reference
diagram for understanding and debugging.


Post a reply to this message

From: Bald Eagle
Subject: Re: Fixing longstanding function/pattern issues in v38. New raw_wave keywor=
Date: 19 Oct 2019 23:05:01
Message: <web.5dabcdf0e43f3c684eec112d0@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> I started documenting longstanding bugs and issues with VM function and
> pattern interplay. I believe as many as possible should be fixed in the
> POV-Ray v3.8 release. Documenting these bugs/issues as I do my best to
> find and fix them in my personal version of POV-Ray.

Well, I think I found an issue with the way that the angle is calculated for the
radial pattern.

 if ((fabs(EPoint[X])<0.001) && (fabs(EPoint[Z])<0.001))
 {
  value = 0.25;
 }
 else
 {
  value = 0.25 + (atan2(EPoint[X],EPoint[Z]) + M_PI) / TWO_M_PI;
 }

 return(value);

If you plot out the values as you go around the unit circle, there's this weird
90-degree "burp" at the 270 degree mark (Theta = 3pi/4 = 4.712) or x=0, z=-1,
which I think is due to the ... + M_PI) / TWO_M_PI part of the equation.

And you can see it as a distinct discontinuity if you render a torus with a
color map like
#declare CM_GreenRedGradient =
color_map {
 [0.0  rgb <0.0, 1.0, 0.0>]
 [0.125  rgb <0.0, 0.0, 0.0>]
 [0.4  rgb <0.0, 0.0, 0.0>]
 [1.0  rgb <1.0, 0.0, 0.0>]
}
and a frequency of 360/270
so that the color and the black show the jump.


This seems to fix it (in my SDL model scene):
#declare Angle = function (XX,ZZ) {atan2 (XX, ZZ)-(pi/2)}
#declare Adjusted = function (XX,ZZ) {select (Angle(XX,ZZ),  Angle(XX,ZZ)+tau,
Angle(XX, ZZ))}
#declare FreqPhase = function (XX, ZZ, F, P) {mod ((P*tau+Adjusted (XX, ZZ))*F,
tau)/tau}

It's late and I'm tired, so I'm making more mistakes and so I'm not going to
play around too much more with this tonight.  But I do believe this is a real
"bug" in the formula, simply due to the numeric #debug output of the formula and
the sharp discontinuity in the color mapped result.

I believe the expected result should be: the color map starts at 0 (<1, 0>),
works it's way around in the y direction, until it hits frequency F, and then
start at the beginning of the color map: entry [0.0 .....].
From what I can determine with my limited experiments, it does not do this.

In the attached render, I have the two small tori, with f=360/90=4, and
f=360/270=1.333....
The two on the left are the native radial pattern with no phase adjustment.
The two on the right are my pattern{function{}} versions with the "fixed"
formulas.

The large center circle is two Segment_of_Torus () objects, textured and rotated
into proper position like I wanted.

I think the fact that the two small tori with f=4 look identical, and so this
has been lurking unseen, since I noticed that it can be very hard to pick out if
you don't know it exists, and are using a color map specifically designed to
expose it.

Let me know what you think.


Post a reply to this message


Attachments:
Download 'radialrotation.png' (145 KB)

Preview of image 'radialrotation.png'
radialrotation.png


 

From: William F Pokorny
Subject: Re: Fixing longstanding function/pattern issues in v38. New raw_wave keywor=
Date: 20 Oct 2019 09:57:14
Message: <5dac67ba$1@news.povray.org>
On 10/19/19 11:01 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
...
> 
> Well, I think I found an issue with the way that the angle is calculated for the
> radial pattern.
> 
...

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.

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.

In the top row, left column looking at the RadialPattern::EvaluateRaw() 
output values directly using my new raw_wave keyword. 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.

The current method works for f>1 integers as can be seen with frequency 
2 in the second row, left column. Where I used 360/270 as you did, we 
expose the discontinuity on the right of the second row.

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. 


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.

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

Bill P.


Post a reply to this message


Attachments:
Download 'radialstory.png' (139 KB)

Preview of image 'radialstory.png'
radialstory.png


 

From: Bald Eagle
Subject: Re: Fixing longstanding function/pattern issues in v38. New raw_wave keywor=
Date: 20 Oct 2019 12:15:01
Message: <web.5dac87642c2efad44eec112d0@news.povray.org>
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

From: Bald Eagle
Subject: Re: Fixing longstanding function/pattern issues in v38. New raw_wave keywor=
Date: 20 Oct 2019 13:20:00
Message: <web.5dac96f32c2efad44eec112d0@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> 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.


Post a reply to this message


Attachments:
Download 'radialphase.png' (140 KB)

Preview of image 'radialphase.png'
radialphase.png


 

From: William F Pokorny
Subject: Re: Fixing longstanding function/pattern issues in v38. New raw_wave keywor=
Date: 22 Oct 2019 04:57:32
Message: <5daec47c$1@news.povray.org>
On 10/20/19 1:18 PM, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> 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'
radialfix_wphase.png


 

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.