|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |