The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Opened by Simon - 2012-02-20
Last edited by William F Pokorny - 2017-03-03
FS#237 - Glitch in displaying rendered pixels and percentage
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.
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.
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?
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 totalThis should be done seperately for
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.
Now tracked on github as issue #247.