|
|
|
|
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Function / pattern issues. Updating cubic_wave.
Date: 5 Apr 2020 12:12:03
Message: <5e8a0353$1@news.povray.org>
|
|
|
| |
| |
|
|
Previous postings:
http://news.povray.org/povray.beta-test.binaries/thread/%3C5da21410%40news.povray.org%3E/
http://news.povray.org/povray.beta-test.binaries/thread/%3C5dab3f55%241%40news.povray.org%3E/
http://news.povray.org/povray.beta-test.binaries/thread/%3C5dbc6985%241%40news.povray.org%3E/
and
http://news.povray.org/povray.beta-test.binaries/thread/%3C5dd8006c%241%40news.povray.org%3E/
As discussed previously, I've added a new wave modifier mode called
function_interval which works in the -1 to 1 range instead of the usual
pattern range of 0 to 1. As part of this working to update all the
existing *_wave modifiers to work in both ranges.
Found with the cubic_wave (does anyone really use it today?) when, eons
ago, the inversion of negative values was introduced to get continuity
(non-flipping at) while moving from negative to positive values through
0.0 the cubic pattern was apparently not updated and the continuity was
mostly broken for it as can be seen in the upper left of the attached
image applying it to a gradient x pattern.
I worked to fix this, but then could see no advantage for cubic_wave
over what we already have with sine_wave. I was going to delete it, but
have decided for povr, to change the existing cubic wave modifier for
both ranges into a bump (selection) function of sorts. The result of
this can be seen in the upper right of the attached image again applying
it against a gradient x pattern.
Today if we try a pattern with cubic_wave like:
granite cubic_wave frequency 3.3 phase -0.5
and use it as an offset to the y plane in an isosurface, we get the
lower right results in the attached image. It's something, but it has
awful continuity and is really useful only for noisy results of one kind
or another.
In the lower right is the bump function result with runs in nearly 1/3
the time because it maintains the incoming continuity while providing
for results much more likely to be useful.
Bill P.
Post a reply to this message
Attachments:
Download 'cubicwavestory.png' (207 KB)
Preview of image 'cubicwavestory.png'
|
|
| |
| |
|
|
From: Alain Martel
Subject: Re: Function / pattern issues. Updating cubic_wave.
Date: 5 Apr 2020 12:57:44
Message: <5e8a0e08$1@news.povray.org>
|
|
|
| |
| |
|
|
Le 2020-04-05 à 12:12, William F Pokorny a écrit :
> Previous postings:
>
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5da21410%40news.povray.org%3E/
>
>
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5dab3f55%241%40news.povray.org%3E/
>
>
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5dbc6985%241%40news.povray.org%3E/
>
>
> and
>
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5dd8006c%241%40news.povray.org%3E/
>
>
> As discussed previously, I've added a new wave modifier mode called
> function_interval which works in the -1 to 1 range instead of the usual
> pattern range of 0 to 1. As part of this working to update all the
> existing *_wave modifiers to work in both ranges.
>
> Found with the cubic_wave (does anyone really use it today?) when, eons
> ago, the inversion of negative values was introduced to get continuity
> (non-flipping at) while moving from negative to positive values through
> 0.0 the cubic pattern was apparently not updated and the continuity was
> mostly broken for it as can be seen in the upper left of the attached
> image applying it to a gradient x pattern.
>
> I worked to fix this, but then could see no advantage for cubic_wave
> over what we already have with sine_wave. I was going to delete it, but
> have decided for povr, to change the existing cubic wave modifier for
> both ranges into a bump (selection) function of sorts. The result of
> this can be seen in the upper right of the attached image again applying
> it against a gradient x pattern.
>
> Today if we try a pattern with cubic_wave like:
>
> granite cubic_wave frequency 3.3 phase -0.5
>
> and use it as an offset to the y plane in an isosurface, we get the
> lower right results in the attached image. It's something, but it has
> awful continuity and is really useful only for noisy results of one kind
> or another.
>
> In the lower right is the bump function result with runs in nearly 1/3
> the time because it maintains the incoming continuity while providing
> for results much more likely to be useful.
>
> Bill P.
>
>
This looks like an improvement.
As I very rarely encounter that wave type, i don't think that it will
break anything.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain Martel <kua### [at] videotronca> wrote:
> Le 2020-04-05 à 12:12, William F Pokorny a écrit :
> This looks like an improvement.
> As I very rarely encounter that wave type, i don't think that it will
> break anything.
Having had to ascend the learning curve to the point where I read source code
and re-write everything from pattern functions to how the color is mapped, to
the point where I uncover malfunctioning code that's been lurking for 20+
years....
It's a PITA to have to do all that because some function that I want is not
accessible internally, or the output that I wrest from SDL is not sufficiently
suitable for further use (no vector-result functions).
That isosurface using the old cubic function is a nasty, gnarly looking thing
that would be useful and desirable for rendering organic growths.
Consider the render and response to:
http://news.povray.org/povray.binaries.images/message/%3Cweb.5d2f9172746ba36d4eec112d0%40news.povray.org%3E/#%3Cweb.5d2
f9172746ba36d4eec112d0%40news.povray.org%3E
So, I'd say keep the original cubic wave, but implement it in some other way,
such as in an updated function include file, a way to specify what is used,
perhaps with a new "wave_set" argument, such as how we now can select which
default noise generator is used, or tack it on as some other numbered internal
function.
But don't delete it.
We have a user-defined pattern, a user-defined camera,
http://wiki.povray.org/content/Reference:User_Defined_Pattern
http://wiki.povray.org/content/Reference:Camera#User_defined_projection
(etc if there are more such things)
It would be ideal to have a user-defined option for all things - noise
functions, turbulence, ... and wave types.
So maybe that's a long-term option to ponder while you're in the midst of all
this.
Great work as always, Bill. You are seemingly indefatigable.
All the best.
In the words of Truthstream Media, "We're Living in 12 Monkeys."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|