POV-Ray : Newsgroups : povray.beta-test.binaries : Function / pattern issues. Updating cubic_wave. Server Time
19 Apr 2024 21:45:24 EDT (-0400)
  Function / pattern issues. Updating cubic_wave. (Message 1 to 3 of 3)  
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'
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

From: Bald Eagle
Subject: Re: Function / pattern issues. Updating cubic_wave.
Date: 5 Apr 2020 14:00:00
Message: <web.5e8a1b99aae34904fb0b41570@news.povray.org>
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

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