POV-Ray : Newsgroups : povray.beta-test : POV-Ray v3.8.0-alpha.9861167 Server Time
29 Mar 2024 11:21:56 EDT (-0400)
  POV-Ray v3.8.0-alpha.9861167 (Message 5 to 14 of 28)  
<<< Previous 4 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: clipka
Subject: Re: POV-Ray v3.8.0-alpha.9861167
Date: 5 Oct 2018 15:04:01
Message: <5bb7b5a1$1@news.povray.org>
Am 05.10.2018 um 20:33 schrieb Alain:

> I expected some message about the max_gradient found to be around 9 but
> set at 1.0.
> The resulting image show obvious holes.
> 
> But, I don't get any message after the render is complete.

Can't reproduce:

- I only see an (almost perfect) clay-brown slab, even with the
max_gradient 1 setting. No holes for me.

- Previous versions (tested with v3.7) do not produce a max_gradient
warning for this scene either. [*]

- When I set max_gradient even lower (0.1), I do get holes, but I also
do get a warning with alpha.9861167. [*]

- The reported maximum gradient found is 0.990, not around 9.


[* Fun side note: At a max_gradient setting of 0.1, it is POV-Ray v3.7
that fails to issue a warning.]


Post a reply to this message

From: Thomas de Groot
Subject: Re: POV-Ray v3.8.0-alpha.9861167
Date: 6 Oct 2018 02:48:26
Message: <5bb85aba$1@news.povray.org>
On 5-10-2018 20:33, Alain wrote:
> Le 18-10-05 à 11:08, clipka a écrit :
>> Am 04.10.2018 um 17:53 schrieb Alain:
>>> I no longer see the post render info when using isosurfaces with
>>> improper max_gradient.
>>
>> Can you provide a sample scene, and what exactly you'd expect?
>>
> 
> #version 3.8;
> global_settings{assumed_gamma 1}
> #declare tip = function(Vert) { sqrt(6.25 - pow(Vert,2)) - 1.5 }
> #declare rad = function(H) {(H*H+1) / max(H,1e-6) / 2}
> #declare hgt = function(x,R,H) { sqrt(pow(R,2) - pow(x,2)) + H - R }
> #declare hght= function(x,H) { hgt(x, rad(H), H) }
> #declare height=function(x,y) { hght(x, tip(y+1)) }
> 
> #declare OBJ=isosurface {
>      function { z * (z - hght(x, tip(y+1))) }
>      threshold 0
>      //max_gradient 9 // the original
>      max_gradient 1 // for this test
>      contained_by {box {<-1,-1,0>, <1,1,1>}}
>    }
> 
> object{OBJ pigment{rgb <1,0.5,0.3>}}
> camera{location -7*z look_at 0}
> light_source{<25,25,-25> rgb 1}
> 
> I expected some message about the max_gradient found to be around 9 but 
> set at 1.0.
> The resulting image show obvious holes.
> 
> But, I don't get any message after the render is complete.
> 
> 
> Alain

Isn't this the typical "naked" isosurface syndrome? i.e. a #declared 
isosurface do /not/ show warning messages, simply provide the isosurface 
as-is, does instead.

Try instead, without the #declare:

isosurface {
       function { z * (z - hght(x, tip(y+1))) }
       threshold 0
       //max_gradient 9 // the original
       max_gradient 1 // for this test
       contained_by {box {<-1,-1,0>, <1,1,1>}}
       pigment{rgb <1,0.5,0.3>}
     }


-- 
Thomas


Post a reply to this message

From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-alpha.9861167
Date: 6 Oct 2018 07:14:13
Message: <5bb89905$1@news.povray.org>
On 10/05/2018 03:04 PM, clipka wrote:
> Am 05.10.2018 um 20:33 schrieb Alain:
> 
>> I expected some message about the max_gradient found to be around 9 but
>> set at 1.0.
>> The resulting image show obvious holes.
>>
>> But, I don't get any message after the render is complete.
> 
> Can't reproduce:
> 
> - I only see an (almost perfect) clay-brown slab, even with the
> max_gradient 1 setting. No holes for me.
> 
> - Previous versions (tested with v3.7) do not produce a max_gradient
> warning for this scene either. [*]
> 
> - When I set max_gradient even lower (0.1), I do get holes, but I also
> do get a warning with alpha.9861167. [*]
> 
> - The reported maximum gradient found is 0.990, not around 9.
> 
> 
> [* Fun side note: At a max_gradient setting of 0.1, it is POV-Ray v3.7
> that fails to issue a warning.]
> 

I do see a few apparent holes (no AA) in the upper let corner for 
example, but otherwise agree with Christoph.

I think the bounding is off with z low being zero:

  contained_by {box {<-1,-1,0>, <1,1,1>}}

In other words, I think the function is mostly being clipped so we are 
seeing a slice of the function's "inside" and which on that slice is 
noisy at the edges. Change that zlow bounding 0 to -1, for example, and 
you'll get gradient warnings for the max gradient of 1.

Aside 1: Another way to clean up the edges in the clipped (zlow=0) case 
is to crank the accuracy way up so the clipped inside resolves more 
cleanly at the edges. Say maybe 0.00005 or less.

Aside 2: IIRC there is still a thread collision in the current 
implementation (which Thomas, in 3.8 no longer needs to be "naked" 
thanks to Christoph's updates) - meaning you are not guaranteed to see 
the very worst found gradient. In practice it's close. Practical 
implication is you need to bump any reported max a little for the 
setting not so much for result, but to be sure some later render doesn't 
report a slightly larger gradient just due the internal ordering of 
stuff.

Bill P.


Post a reply to this message

From: Thomas de Groot
Subject: Re: POV-Ray v3.8.0-alpha.9861167
Date: 7 Oct 2018 02:29:19
Message: <5bb9a7bf$1@news.povray.org>
On 6-10-2018 13:14, William F Pokorny wrote:
> Aside 2: IIRC there is still a thread collision in the current 
> implementation (which Thomas, in 3.8 no longer needs to be "naked" 
> thanks to Christoph's updates) - meaning you are not guaranteed to see 
> the very worst found gradient. In practice it's close. Practical 
> implication is you need to bump any reported max a little for the 
> setting not so much for result, but to be sure some later render doesn't 
> report a slightly larger gradient just due the internal ordering of stuff.
> 

Good! Progress passing me by :-)

Thanks for the info.

-- 
Thomas


Post a reply to this message

From: jr
Subject: Re: POV-Ray v3.8.0-alpha.9861167
Date: 7 Oct 2018 10:20:01
Message: <web.5bba1523ef23b962b0d4fc1e0@news.povray.org>
hi,

clipka <ano### [at] anonymousorg> wrote:
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9861167

playing around with some code, I get:

  File 'tstlq.pov' line 40: Parse Error: Tried to free undefined symbol
  Fatal error in parser: Cannot parse input.

the problem is, the file ends at line 39.  :-)  line 38 contains an
'#undef' which destroys a variable '#declare'd in same file.

archive with scene to same email?

regards, jr.


Post a reply to this message

From: clipka
Subject: Re: POV-Ray v3.8.0-alpha.9861167
Date: 8 Oct 2018 11:05:01
Message: <5bbb721d$1@news.povray.org>
Am 07.10.2018 um 16:16 schrieb jr:

>   File 'tstlq.pov' line 40: Parse Error: Tried to free undefined symbol
>   Fatal error in parser: Cannot parse input.
> 
> the problem is, the file ends at line 39.  :-)  line 38 contains an
> '#undef' which destroys a variable '#declare'd in same file.
> 
> archive with scene to same email?
> 
> regards, jr.

The usual procedure, yes.


Post a reply to this message

From: StephenS
Subject: Re: POV-Ray v3.8.0-alpha.9861167 - Work_Threads
Date: 14 Oct 2018 16:26:34
Message: <5bc3a67a$1@news.povray.org>
On 2018-09-30 11:48 p.m., clipka wrote:
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9861167
> 
While not related to the updated features, this was the winpov64 I used.
Using a newer computer and going though some older scenes.


With no included Work_Threads, or commented out, Work_Threads

Render Time:
   Photon Time:      No photons
   Radiosity Time:   No radiosity
   Trace Time:       0 hours 22 minutes  9 seconds (1329.351 seconds)
               using 3 thread(s) with 3988.077 CPU-seconds total
POV-Ray finished
-
CPU time used: kernel 1.16 seconds, user 3992.17 seconds, total 3993.33 
seconds.
Elapsed time 1331.39 seconds, CPU vs elapsed time ratio 3.00.
Render averaged 2433.55 PPS (811.35 PPS CPU time) over 3240000 pixels.

Adding:
Work_Threads = 32
To my .INI file gave me the following outputs.

Render Time:
   Photon Time:      No photons
   Radiosity Time:   No radiosity
   Trace Time:       0 hours  3 minutes 10 seconds (190.047 seconds)
               using 32 thread(s) with 6039.815 CPU-seconds total
POV-Ray finished
-
CPU time used: kernel 1.03 seconds, user 6043.08 seconds, total 6044.11 
seconds.
Elapsed time 192.08 seconds, CPU vs elapsed time ratio 31.47.
Render averaged 16867.97 PPS (536.06 PPS CPU time) over 3240000 pixels.


Is there a default some where?

WinPov editor:
Render/Thread Count is set to 32

StephenS


Post a reply to this message

From: clipka
Subject: Re: POV-Ray v3.8.0-alpha.9861167 - Work_Threads
Date: 15 Oct 2018 02:08:22
Message: <5bc42ed6$1@news.povray.org>
Am 14.10.2018 um 22:26 schrieb StephenS:

> While not related to the updated features, this was the winpov64 I used.
> Using a newer computer and going though some older scenes.
> 
> 
> With no included Work_Threads, or commented out, Work_Threads
> 
> Render Time:
>   Photon Time:      No photons
>   Radiosity Time:   No radiosity
>   Trace Time:       0 hours 22 minutes  9 seconds (1329.351 seconds)
>               using 3 thread(s) with 3988.077 CPU-seconds total
> POV-Ray finished

...
> Is there a default some where?

Yes:

> WinPov editor:
> Render/Thread Count is set to 32

To the best of my knowledge, the mechanism in POV-Ray for Windows is as
follows:

- The number of threads set in the "Render Thread Count" dialog is the
default for each render.

- Any change you make in the dialog is only valid for the current
session; if you close POV-Ray and re-start it, the dialog is
re-populated with the number of cores as reported by the operating system.

- Any `+wtN`, `-wtN` or `Work_Threads=N` in any applicable INI file will
override this setting.

- Any `+wtN`, `-wtN` or `Work_Threads=N` specified in the so-called
"command line" inut field will also override this setting.

- Any `+wtN`, `-wtN` or `Work_Threads=N` passed to the POV-Ray
executable as an actual command line parameter should also affect the
setting, though I'm not sure whether it will change the value in the
dialog or be equivalent to setting it in an INI file. My guess is the
latter.


Obviously the "Render Thread Count" dialog is not initialized to 3 in
your case, so the core count auto-detection works fine, and there must
be /something/ overridding the default.

The master `povray.ini` as well as any `povray.ini` in the same
directory as the scen come to mind.


Post a reply to this message

From: StephenS
Subject: Re: POV-Ray v3.8.0-alpha.9861167 - Work_Threads
Date: 15 Oct 2018 05:54:03
Message: <5bc463bb$1@news.povray.org>
On 2018-10-15 2:08 a.m., clipka wrote:
...
> The master `povray.ini` as well as any `povray.ini` in the same
> directory as the scen come to mind.
> 

Good call, there was indeed a povray.ini in the same directory.

Separately, I will no longer be reporting WinXP32 feedback unless asked. 
The computer is no longer plugged in with all of it's parts.

StephenS


Post a reply to this message

From: jr
Subject: Re: POV-Ray v3.8.0-alpha.9861167
Date: 17 Oct 2018 10:00:01
Message: <web.5bc73fbfef23b9626427f7f90@news.povray.org>
hi,

clipka <ano### [at] anonymousorg> wrote:
> > archive with scene to same email?
> The usual procedure, yes.

did you receive the email?


regards, jr.


Post a reply to this message

<<< Previous 4 Messages Goto Latest 10 Messages Next 10 Messages >>>

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