While thinking of deleting the quilted value pattern, started to toy 
with the idea of replacing it with a seed pattern having values in the 
function_interval range of -1 to 1.

The wave shape modifiers have been extended to support +- function 
values, but to make use of them without some seed, you need to create 
functions as input.

What if we had one or more seed or base patterns aimed at being fuel for 
more complex patterns?

Idea thus far looks promising.Two images attached. One showing the 
concept from seed pattern through to more complex patterns derived from 
it. The other a larger fall color image using the technique.

A - The seed pattern on a y plane. Negative values as red and positive 
values as green. The black between the near 0 values.(using 
function_interval)

B - What is in A, but used directly in an isosurface.

C - Combining two of A in an average pigment. (function_interval)

D - Pattern of C as an isosurface.

E - C pattern (adding sine_wave along with function_interval)

F - Using E in an isosurface.

G - Adding six more rotations of A to the C average pigment.

H - G using the modified povr cubic_wave (selection) functionality.

I - H adding phase -0.1 to shift the colors toward negative red.

J - H again with phase +0.1 and adding some turbulence.

K - J adding the povr wave inverse wave keyword.

L - J made more turbulent. Adding a light to the scene.

Bill P.

Post a reply to this message

Attachments:
Download 'seedpattrnstory.jpg' (438 KB) Download 'fallcolors.jpg' (285 KB)

Preview of image 'seedpattrnstory.jpg'

Preview of image 'fallcolors.jpg'

On 10/11/20 2:14 PM, William F Pokorny wrote:
> While thinking of deleting the quilted value pattern, started to toy 
> with the idea of replacing it with a seed pattern having values in the 
> function_interval range of -1 to 1.
> 
...
> 
> J - H again with phase +0.1 and adding some turbulence.
> 
> K - J adding the povr wave inverse wave keyword.
> 
> L - J made more turbulent. Adding a light to the scene.
> 

One more isosurface image using something similar to L to displace a 
surface.

It reminds me a little of a tunnel I once traversed. A tunnel created by 
blasting through solid rock.

Bill P.

Post a reply to this message

Attachments:
Download 'hmmhmm.jpg' (295 KB)

Preview of image 'hmmhmm.jpg'

On 10/11/20 2:14 PM, William F Pokorny wrote:
> While thinking of deleting the quilted value pattern, started to toy 
> with the idea of replacing it with a seed pattern having values in the 
> function_interval range of -1 to 1.
> 
...

One more. I had thought I could create another image where I scale the 
seed derived pattern very small creating a really good stress tests for 
the am3 anti-alias mode.

Since that set of cases am1,am2,am3 cases making sure there was no 
overall color shift, I've been carrying this a the am3 mode really worth 
much over heavy am1/am2.

It's valuable here. Fed the input on the left (no AA) - there is  much 
more 'line-ish' detail below what is seen. The am3 mode came out quite a 
bit faster than am2 for equivalent threshold and depth. The fixed am3 
and confidence set at 0.98. Resulting images not identical, but very close.

3 minutes 56 seconds (236.791 seconds)   am3
Pixels: 490000 Samples: 425852553 Smpls/Pxl: 869.09

5 minutes 30 seconds (330.180 seconds)   am2
Pixels: 521284 Samples: 531634923 Smpls/Pxl: 1019.86

869.09 -> 1019.9 ---> 17.35%
236.8s -> 330.2s ---> 39.44%

Bill P.

Post a reply to this message

Attachments:
Download 'am2vsam3.jpg' (131 KB)

Preview of image 'am2vsam3.jpg'

On 10/12/20 10:15 AM, William F Pokorny wrote:
> I've been carrying this a the am3 mode really worth much over heavy am1/am2.

Argh... Should have read something like:

"I've been carrying this doubt whether the am3 mode really worth much 
over heavy am1/am2."

With the example posted, it's the best choice.

Bill P.

Post a reply to this message

On 10/13/20 4:13 AM, William F Pokorny wrote:
> On 10/12/20 10:15 AM, William F Pokorny wrote:
...
> 
> With the example posted, it's the best choice.
> 

And should add another very good reason to keep - and use - aa method 3 
is the stochastic seed capability. This lets us get a repeatable aa 
method 1, 2 type result without the randomness of the jitter in methods 
one and two.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> It's valuable here. Fed the input on the left (no AA) - there is  much
> more 'line-ish' detail below what is seen. The am3 mode came out quite a
> bit faster than am2 for equivalent threshold and depth. The fixed am3
> and confidence set at 0.98. Resulting images not identical, but very close.
>
> With the example posted, it's the best choice.

So just to be clear: The image on the left is with NO AA, and the image on the
right is with the stochastic am3 method? That looks really good.
>
>
> And should add another very good reason to keep - and use - aa method 3
> is the stochastic seed capability. This lets us get a repeatable aa
> method 1, 2 type result without the randomness of the jitter in methods
> one and two.
>

So it seems to be the best thing to use for AA in animations... although there
are two notes in the documentation:
"Conversely you can produce exactly the same output each time. See also:
Stochastic Seed."

That sounds good. But...
"Note: The jitter sequence is also affected by the actual image content, and
will thus always differ between the frames of an animation."

If I understand this correctly, it makes me wonder if there *would* be a
visually noticiable jittering when using the am3 method. I guess I need to try
it, to see.

Thanks for these tests.

Post a reply to this message

On 10/19/20 9:15 AM, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> If I understand this correctly, it makes me wonder if there *would* be a
> visually noticiable jittering when using the am3 method. I guess I need to try
> it, to see.
> 
Good

Good question! I don't believe jitter is used in am3, but I did not test 
that belief. Let us know what you find.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/19/20 9:15 AM, Kenneth wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >
> > If I understand this correctly, it makes me wonder if there *would* be a
> > visually noticiable jittering when using the am3 method. I guess I need to try
> > it, to see.
> >
>
> Good question! I don't believe jitter is used in am3, but I did not test
> that belief. Let us know what you find.
>

I just tried to test it, but it's throwing an error.

I'm running the latest v3.8 development build in Windows, but it does not accept
the   Antialias_Confidence=  keyword in my quickres.ini file(!)

[1280x960, AA special]
Width=1280
Height=960
Antialias=On
Sampling_Method=3
Antialias_Confidence=0.98  <------- not accepted
Antialias_Threshold=0.05

I tried instead to use +AC0.98 on the command line, but it does not work there
either. I don't know what I'm doing wrong. Help!

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I just tried to test it, but it's throwing an error.
>
> I'm running the latest v3.8 development build in Windows, but it does not accept
> the   Antialias_Confidence=  keyword in my quickres.ini file(!)
> ...
> I tried instead to use +AC0.98 on the command line, but it does not work there
> either. I don't know what I'm doing wrong. Help!

I forgot to mention that Stochastic_Seed (or +SS) is not accepted either, in
either location.

It seems that v3.8 in Windows is not recognizing those terms. :-(  If I leave
them out completely, I AM able to render-- but without the Stochastic_Seed
mechanism, I can't do a 'thorough' animation test for possible jitter.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> I forgot to mention that Stochastic_Seed (or +SS) is not accepted either, in
> either location.
>
> It seems that v3.8 in Windows is not recognizing those terms. :-(

I did an animation test anyway, by simply leaving out the two terms.

my .ini file:
[1280x960, AA special]
Width=1280
Height=960
Antialias=On
Sampling_Method=3
Antialias_Threshold=0.05

Nothing moves in my scene, or the camera; just static animation frames. I took
two consecutive frames into Photoshop, 'differenced' them, and exaggerated any
possible defects. And I don't see ANY difference between the two images-- no
out-of-place pixles at all. :-) Perhaps Stochastic_Seed is already 'on' by
default in the Windows version(?). In any case, the renders are beautifully
antialiased, and consistent.

Perhaps a *moving* camera might show something-- but any am3 difference from
frame to frame would be hard to verify by itself, since everything else is
slightly changing as well.

Post a reply to this message

On 10/19/20 6:29 PM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> 
>>
>> I forgot to mention that Stochastic_Seed (or +SS) is not accepted either, in
>> either location.
>>
>> It seems that v3.8 in Windows is not recognizing those terms. :-(
> 
> I did an animation test anyway, by simply leaving out the two terms.
> 
> my .ini file:
> [1280x960, AA special]
> Width=1280
> Height=960
> Antialias=On
> Sampling_Method=3
> Antialias_Threshold=0.05
> 
> Nothing moves in my scene, or the camera; just static animation frames. I took
> two consecutive frames into Photoshop, 'differenced' them, and exaggerated any
> possible defects. And I don't see ANY difference between the two images-- no
> out-of-place pixles at all. :-) Perhaps Stochastic_Seed is already 'on' by
> default in the Windows version(?). In any case, the renders are beautifully
> antialiased, and consistent.
> 
> Perhaps a *moving* camera might show something-- but any am3 difference from
> frame to frame would be hard to verify by itself, since everything else is
> slightly changing as well.
> 

My only guess is you have a version which doesn't completely support 
method 3 AA. Did you review the render messages back to the screen? In
the unix based versions we see something like:


   Antialiasing.........On  (Method 2, Threshold 0.100, Depth 3,
                             Jitter 1.00, Gamma 2.50)

Asking because in regular POV-Ray specifying a mode greater than really 
supported defaults to the largest really supported. Are you seeing 
"Method 3" in the text output?

---
... Maybe my thinking about am3 being better for animations due no 
jitter is bogus. Maybe even some of our thinking and documentation about 
jitter frame to frame. Seems like I used to get render to render 
differences with jitter on - it's why I forever have turned it off when 
I do image to image compares.

Trying now I - like you - cannot get a difference... There is something 
I don't understand about jitter and AA! Is it today (v3.7+) really 
random render to render? Are we getting some pre-seeded psuedo random 
jitter?

Busy the next couple of days, but need to look more at this.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> My only guess is you have a version which doesn't completely support
> method 3 AA. Did you review the render messages back to the screen?
> ...
> Asking because in regular POV-Ray specifying a mode greater than really
> supported defaults to the largest really supported. Are you seeing
> "Method 3" in the text output?
>
Running the v3.8-alpha.9811560+av591.msvc14 development build in Windows, with a
1280X960 render:

Antialiasing....on (method 2, Threshold 0.050, Depth 3, Jitter 1.00,  Gamma
2.50)
Samples:  10378994         Smpls/Pxl:  7.94

I didn't think to look there --and you are correct, it is falling back to AA
method 2, and WITH jitter(!). Thanks for the tip. It seems odd that I don't
*see* any animation jitter...although I'm not complaining!  ;-)

[off-topic]:
Strange thing: This development build that I'm currently running within v3.7.0
-- the replacement 'pvengine64' file-- came from a folder labeled
    povray-3.8.0-x.10064738-av694-Win64
(which is the name it un-Zipped to when I downloaded it.) But the version
numbers don't match.

I think I'll check out some of the other v3.8-alpha builds that I have, to see
if *any* of them will run the new  am3 AA  successfully.

Post a reply to this message

On 10/20/20 8:22 AM, Kenneth wrote:
> I didn't think to look there --and you are correct, it is falling back to AA
> method 2, and WITH jitter(!). Thanks for the tip. It seems odd that I don't
> *see*  any animation jitter...although I'm not complaining!

Excepting it "might" mean single frame renders don't have access to the 
best AA quality. This a reason for render to render AA 'random' jitter.

Aside: I've long been carrying a feeling, a notion, an idea the am1/am2 
AA in v3.7/v3.8 is a little less good. Hard to really determine because 
of all the assumed gamma change plus now +ag2.5 mixed into the AA 
itself. Maybe jitter handling changed v3.6->v3.7 ?

Bill P.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > I'm running the latest v3.8 development build in Windows [and trying to use
> > the new AA3 antialias method] but it does not accept
> > the   Antialias_Confidence=  keyword.
> > ...
> > I tried instead to use +AC0.98 on the command line, but it does not work there
> > either.
> ...
> I forgot to mention that Stochastic_Seed (or +SS) is not accepted either.
>
> It seems that v3.8 in Windows is not recognizing those terms.

Just to follow up:
I have five different v3.8 'development versions' from Github (which run within
v3.7.0), and I have tried them all: The new antialias mode is not recognized in
any of them; they all revert to method 2. It seems that this new method was
never actually implemented in these Windows development builds of 3.8x (or else
maybe in one of the versions that I haven't yet tried??) Sad news. From reading
other posts here, method 3 apparently does work in Linux compiles of the source
code. So I guess that the relevant new code *is* sitting somewhere in the 3.8
source code itself?

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > > I'm running the latest v3.8 development build in Windows ...
> Just to follow up:
> I have five different v3.8 'development versions' from Github (which run within
> v3.7.0), and I have tried them all: The new antialias mode is not recognized in
> any of them; ...

I have never run POV-Ray on Windows but (now) wonder whether any of those five
versions, if installed rather than "piggybacked" onto a previous, would not work
"as advertised".


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > I have five different v3.8 'development versions' from Github [for
> > Windows]...The new antialias mode is not recognized in
> > any of them
>
> I have never run POV-Ray on Windows but (now) wonder whether any of those five
> versions, if installed rather than "piggybacked" onto a previous, would not work
> "as advertised".
>

Good question. AFAIK, no complete .exe/installable of v3.8 has yet been made for
Windows. (I don't have the tech know-how to compile one from the source code,
sorry to say.)

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > "Kenneth" <kdw### [at] gmailcom> wrote:
> > > I have five different v3.8 'development versions' from Github [for
> > > Windows]...The new antialias mode is not recognized in
> > > any of them
> >
> > I have never run POV-Ray on Windows but (now) wonder whether any of those five
> > versions, if installed rather than "piggybacked" onto a previous, would not work
> > "as advertised".
>
> Good question. AFAIK, no complete .exe/installable of v3.8 has yet been made for
> Windows. (I don't have the tech know-how to compile one from the source code,
> sorry to say.)

re compile from source, all versions I have installed are labelled "POV-Ray v3.x
for UNIX/Linux" (in the README/INSTALL files), so cannot comment on the Windows
thing.  however, if you were to install MS Visual Studio (there's a free edition
for non-commercial use), I'm certain people here could/would offer support for
the actual compilation/procedure.


regards, jr.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Just to follow up:
> I have five different v3.8 'development versions' from Github (which run within
> v3.7.0), and I have tried them all: The new antialias mode is not recognized in
> any of them; they all revert to method 2. It seems that this new method was
> never actually implemented in these Windows development builds of 3.8x (or else
> maybe in one of the versions that I haven't yet tried??)...

Well, I was WRONG about that, and I apologize for the misinformation.

The new antialias Method 3 DOES work successfully in the *latest* v3.8
development build for Windows,   10064738+av694 ("experimental")

I thought I had tried that one-- it's in my collection-- but apparently not. (Or
maybe I mis-read the message pane at the time.) So I have finally been able to
do some tests with it, using all .png renders except for this final image.

My AA rendering values in my INI file were  somewhat basic:
Antialias=on
Sampling_method=3 (or 2)
Antialias_Threshold=0.05
Stochastic_Seed=7 (or not used at all)
(the other values/keywords are at their defaults)

The differenced images here are exaggerated of course, to show the pixel changes
of the jitter effect. (I also applied some sharpening in Photoshop, to show any
Moire patterns better.)

The 'automatic' use of AM3 jitter from render to render seems to work as
advertised. And with Stochastic_Seed 'on' (with some integer seed value), there
is NO pixel difference between renders, OR between rendered animation frames--
jitter is successfully turned off. That's good news for animations.

BTW, there is NO difference between two renders using AA method 2, even though
the message pane says that Jitter 1.0 is being used-- which agrees with
William's tests about previous versions of POV-ray, that NO default jitter is
applied. However, *specifying* an actual jitter value does work correctly, and
the message pane returns the correct value.  But from my own tests with this,
the method-2 render actually looks better with NO jitter (the apparent default
value.) With  Jitter_Amount=0.5, any possible Moire patterns in the render are
actually exaggerated(!), at least in conjunction with the rather 'basic' AA
values I used.

Post a reply to this message

Attachments:
Download 'am2_vs_am3_results_for_newsgroups.jpg' (3871 KB)

Preview of image 'am2_vs_am3_results_for_newsgroups.jpg'

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> The 'automatic' use of AM3 jitter from render to render seems to work as
> advertised. And with Stochastic_Seed 'on' (with some integer seed value),
> there is NO pixel difference between renders, OR between rendered animation
> frames--jitter is successfully turned off...
>
Sorry, what I meant to say is that the jitter in animation is the SAME from
frame to frame (not 'off'). So no pixel differences from frame to frame.

Post a reply to this message

On 11/5/20 6:18 PM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>>
>> Just to follow up:
...
> 

Cool. Some of those city-scape differences are artsy on their own.

Bill P.

Post a reply to this message