POV-Ray : Newsgroups : povray.binaries.images : Documenting longstanding issues with ripples and waves. : Documenting longstanding issues with ripples and waves. Server Time: 25 Oct 2020 02:28:24 GMT
  Documenting longstanding issues with ripples and waves.  
From: William F Pokorny
Date: 10 Sep 2020 16:53:53
--- continuous pattern / pattern{} block

In working on povr started digging into the ripples and waves normal{} 
and pattern{} implementations aiming to clean those up and implement 
f_ripples and f_waves inbuilt functions.

Looking at code I think these issues, or variants of them, go back to 
v3.0. In v3.7+, one cannot use frequency and phase values other than the 
default 1 or 0 with ripples or waves in patterns. For example:

pigment { ripples frequency 2.0 }  <-- Mangled result.

Frequency and phase are used in the ripples and waves code. 
Unfortunately, these get applied again in the pattern wave shaping code. 
The effect of this can be seen in the attached image.

In the top row ripples; the bottom waves. In the left column no 
modifications are made to the frequency(1) and phase(0). In the middle 
column, a correct pattern{} result for frequency 2.0. On the right is 
the mangled output we get today. The frequency and phase get used twice 
- though to no harm when the values are the default 1 and 0.

Aside: There is often talk around function continuity when working with 
isosurfaces. Value continuity applies to patterns too when an adaptive 
algorithm is in play. Using the ripples results as an example, and 
running with '+a0.2 +am2 +r2', the CPU times left to right are 0.673, 
1.927 and 4.8 seconds. In other words, the discontinuous ripples pattern 
drives the render time up, 1.927 -> 4.8 ---> 149.09% !

What to do...

In the v3.8 master branch Christoph added a kWaveType_Raw for the 
potential pattern though it was not brought out as a keyword. A quick 
v3.8 fix is to add constructor overrides for the ripples and waves patterns:

RipplesPattern::RipplesPattern() { waveType = kWaveType_Raw; }
WavesPattern::WavesPattern() { waveType = kWaveType_Raw; }

I've done this for the time being in my personal povr branch. 
Documentation based on such a change would be necessary too. If someone 
adds a triangle_wave modifier, for example, you are activating the 
pattern wave shape modification code. We would again be twice applying 
frequency and phase.

Excepting the pattern ripples and waves from the wave shape modification 
code would add the cost of a conditional and being able to apply that 
code is useful. I believe this a bad fix.

FWIW. The permanent fix I plan for povr is to extend the new it_ 
prefixed (internal turbulence for a patterns) keywords concept to i_ 
(internal) versions of keywords when a pattern requires them.

I believe ripples and waves have always needed dedicated handling of 
frequency and phase! So, in povr for ripples/waves the new keywords will 
be i_frequency and i_phase.

--- normal{} block

Some of you are asking, "What does any of this mean for normal{} blocks?"

Frequency and phase today work per our documentation. The wave 
modification code is bypassed for certain normal{} patterns including 
ripples and waves.

Are normals{}s then good? No, not in my opinion.

Today, the parser allows you to code: normal { ripples frequency 2.0 
triangle_wave } with nary a squeak the 'wave type' modifier does nothing.

The behavior is documented in the 'Normal' section:

"Because these six types use specialized normal modification 
calculations they cannot have slope_map, normal_map or wave shape 
modifiers."

It's also noted in other excepted patterns that the wave shape modifiers 
cannot be used.

The documentation for the ripples pattern correctly notes the "wave 
shape modifiers," frequency and phase are in fact used. This, despite 
that contrary sentence in the 'Normal' documentation. The docs go on to 
add you cannot however use any of the "wave type modifiers" with ripples.

Today, I get the subtleties of the wording here, but for new or moderate 
experience users, ouch!

In povr - partly because of additional continuous pattern wave shape 
modifiers such as inverse and function_interval - the plan is to add to 
parse code to generate errors on incorrect wave shape modifier usage in 
the normal{} block.

Bill P.


Post a reply to this message


Attachments:
Download 'story_ripples_waves.jpg' (252 KB)

Preview of image 'story_ripples_waves.jpg'
story_ripples_waves.jpg


 

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