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.

Attached to Project: POV-Ray
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.

Christoph Lipka commented on Monday, 20 February 2012, 14:29 GMT

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.

Simon commented on Tuesday, 21 February 2012, 10:09 GMT

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?

Simon commented on Wednesday, 10 April 2013, 19:30 GMT

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.

William F Pokorny commented on Friday, 03 March 2017, 14:37 GMT

Now tracked on github as issue #247.


Available keyboard shortcuts


Task Details

Task Editing