POV-Ray : Newsgroups : povray.unofficial.patches : Progress Reporting Change? Server Time
5 Nov 2024 15:35:43 EST (-0500)
  Progress Reporting Change? (Message 1 to 6 of 6)  
From: James Holsenback
Subject: Progress Reporting Change?
Date: 31 Dec 2013 06:50:52
Message: <52c2af9c$1@news.povray.org>
Just noticed that progress reporting seems to be different with uber-dev
branch ... talking about the rendered xxx of xxxx (xx%) message.

The % indication /used/ to reset to 0 at the end of each pretrace step, 
before starting the next step. Now it appears that it doesn't reset to 0 
until it starts the final trace.

Other than "preliminary workaround for FS#313" (dated Dec 15th) I didn't 
see anything in the commits listing ... could that be what I'm seeing?


Post a reply to this message

From: Le Forgeron
Subject: Re: Progress Reporting Change?
Date: 31 Dec 2013 08:00:58
Message: <52c2c00a$1@news.povray.org>
Le 31/12/2013 12:50, James Holsenback nous fit lire :
> Just noticed that progress reporting seems to be different with uber-dev
> branch ... talking about the rendered xxx of xxxx (xx%) message.
> 
> The % indication /used/ to reset to 0 at the end of each pretrace step,
> before starting the next step. Now it appears that it doesn't reset to 0
> until it starts the final trace.
> 
> Other than "preliminary workaround for FS#313" (dated Dec 15th) I didn't
> see anything in the commits listing ... could that be what I'm seeing?

That's not 6092 of perforce: only change is commenting assert().

Which branch of uber-dev ? (I assume UperPov, branch develop, isn't it ?)

I was to investigate that counter(s?) one day, as continuing (+C) a
render so far, on unix: does not display the pixels stored in
pov-state.file and the number of render pixels is ok for the current
session, yet the total number is picture dimension (ignoring the already
rendered pixels)... and I would like to see some pps or ppm (both from
beginning and recent average) in addition to the number of pixels during
the progression. But that's a bit off-topic.

Just have to find where it is... But no time on the 31th December.

In the meantime, you can use "git bisect" to find the actual change.


Post a reply to this message

From: James Holsenback
Subject: Re: Progress Reporting Change?
Date: 31 Dec 2013 09:17:14
Message: <52c2d1ea$1@news.povray.org>
On 12/31/2013 08:00 AM, Le_Forgeron wrote:
> Le 31/12/2013 12:50, James Holsenback nous fit lire :
>> Just noticed that progress reporting seems to be different with uber-dev
>> branch ... talking about the rendered xxx of xxxx (xx%) message.
>>
>> The % indication /used/ to reset to 0 at the end of each pretrace step,
>> before starting the next step. Now it appears that it doesn't reset to 0
>> until it starts the final trace.
>>
>> Other than "preliminary workaround for FS#313" (dated Dec 15th) I didn't
>> see anything in the commits listing ... could that be what I'm seeing?
>
> That's not 6092 of perforce: only change is commenting assert().
>
> Which branch of uber-dev ? (I assume UperPov, branch develop, isn't it ?)

you are correct ... sorry for short-hand reference

>
> I was to investigate that counter(s?) one day, as continuing (+C) a
> render so far, on unix: does not display the pixels stored in
> pov-state.file and the number of render pixels is ok for the current
> session, yet the total number is picture dimension (ignoring the already
> rendered pixels)... and I would like to see some pps or ppm (both from
> beginning and recent average) in addition to the number of pixels during
> the progression. But that's a bit off-topic.
>
> Just have to find where it is... But no time on the 31th December.

yes ... it's about time I get up from the computer as well. Need to 
prepare for guests this evening. Happy New Year!

>
> In the meantime, you can use "git bisect" to find the actual change.
>

Oh thanks for the git "nugget"

Jim


Post a reply to this message

From: Alain
Subject: Re: Progress Reporting Change?
Date: 2 Jan 2014 13:17:13
Message: <52c5ad29@news.povray.org>

> Just noticed that progress reporting seems to be different with uber-dev
> branch ... talking about the rendered xxx of xxxx (xx%) message.
>
> The % indication /used/ to reset to 0 at the end of each pretrace step,
> before starting the next step. Now it appears that it doesn't reset to 0
> until it starts the final trace.
>
> Other than "preliminary workaround for FS#313" (dated Dec 15th) I didn't
> see anything in the commits listing ... could that be what I'm seeing?

I noted the same thing with the official version 3.7, back to RC1 and 
maybe earlier. The percent of the pretrace seems to be calculated on the 
TOTAL pretrace process, not on any individual pretrace step.


Alain


Post a reply to this message

From: Alain
Subject: Re: Progress Reporting Change?
Date: 2 Jan 2014 13:21:41
Message: <52c5ae35$1@news.povray.org>
Le 13-12-31 08:00, Le_Forgeron a écrit :

> I was to investigate that counter(s?) one day, as continuing (+C) a
> render so far, on unix: does not display the pixels stored in
> pov-state.file and the number of render pixels is ok for the current
> session, yet the total number is picture dimension (ignoring the already
> rendered pixels)... and I would like to see some pps or ppm (both from
> beginning and recent average) in addition to the number of pixels during
> the progression. But that's a bit off-topic.
>

This may be by design or an oversight. I see the exact same thing on 
Windows. When using +c, the percent completed is correctly displayed 
*untill* the first block is computed and displayed. Then, it shows the 
completed since the moment you resumed the render on the total image size.



Alain


Post a reply to this message

From: clipka
Subject: Re: Progress Reporting Change?
Date: 2 Jan 2014 17:13:44
Message: <52c5e498$1@news.povray.org>
Am 02.01.2014 19:17, schrieb Alain:

>> Just noticed that progress reporting seems to be different with uber-dev
>> branch ... talking about the rendered xxx of xxxx (xx%) message.
>>
>> The % indication /used/ to reset to 0 at the end of each pretrace step,
>> before starting the next step. Now it appears that it doesn't reset to 0
>> until it starts the final trace.

> I noted the same thing with the official version 3.7, back to RC1 and
> maybe earlier. The percent of the pretrace seems to be calculated on the
> TOTAL pretrace process, not on any individual pretrace step.

Yes, that observation is correct, and this behaviour is intentional.


Post a reply to this message

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