Port of FS237 - Glitch in displaying rendered pixels and percentage (Reporting changes)

[wfpokorny]

Port of FS237 - Glitch in displaying rendered pixels and percentage (Feature -Reporting changes)

http://bugs.povray.org/task/237 (As posted by Simon (infoised))

(The radisity glitch still there in 371. In follow up comments other reporting changes requested.)

---

Details:

When rendering in multiple passes (radiosity in my case), the elapsed pixels and percentage, written to terminal are first displayed like this: Rendered 126202 of 360000 pixels (35%) Then on the second stage the output text becomes shorter and you see Rendered 25344 of 360000 pixels (7%)%) The contents of the previous status are not erased, so the longer text persists (note the duplicate percentage sign and closing parenthesis). Such a glitch could have more drastic effect in rare cases.

I'm running Version 3.7.0.RC3 (g++ 4.6.2 x86_64-unknown-linux-gnu) compiled for the Arch Linux package.

---

Comments:

---

Comment by Christoph Lipka (clipka) - Monday, 20 February 2012, 19:29 GMT+5

I don't see where this glitch might have any "drastic effect"; as for scripts evaluating the output, they see all those lines separated by carriage-return characters.

Anyway, I guess it should be easy to fix by printing a newline between stages.

---

Comment by Simon (infoised) - Tuesday, 21 February 2012, 15:09 GMT+5

I just meant the number of leftover characters may be very large in some cases.

Printing a newline is a good solution. Right now there is no indication of which stage the render is in, which makes it hard to estimate the remaining time. Could this also be added?

---

Comment by Simon (infoised) - Thursday, 11 April 2013, 00:30 GMT+5

In addition to this, it appears that during the photon mapping stage, all threads report their counts in parallel, and the displayed number of photons fluctuates a lot: it can change like this Photon count 697 Photon count 1043 Photon count 703 ... It seems to me, that the counts from threads are not added together, but rather just reported separately, whichever comes first. It would be better to add them together for consistent increasing photon count, or report separate counts from different working threads, like Photon count [697,1043,...]= 3423 total Edit: this seems to be commented in the code as a known issue.

While we are at it, it would be nice to report timing for each stage separately. Just like the parse stage and the render stage have a block like this

Parser Time
  Parse Time:       0 hours  0 minutes  8 seconds (8.777 seconds)
            using 1 thread(s) with 8.773 CPU-seconds total

This should be done seperately for

• parsing
• photons
• radiosity (each pass separately, plus total), where it should be indicated which pretrace pass it is
• main render

This avoids the original glitch and also provides the user with information about where we are... I got angry a lot of times, when I returned to the computer, seen the progress at 90% and when it finished, I noticed that it was actually radiosity stage, and the render stage will take even more time.