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