POV-Ray

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.

Tasklist

FS#237 - Glitch in displaying rendered pixels and percentage

Attached to Project: POV-Ray
Opened by Simon (infoised) - Monday, 20 February 2012, 13:27 GMT
Last edited by William F Pokorny (wfpokorny) - Friday, 03 March 2017, 14:37 GMT
Task Type Definite Bug
Category Frontend → User interface
Status Tracked on GitHub
Assigned To Chris Cason (chrisc)
Operating System Linux
Severity Very Low
Priority Low
Reported Version 3.70 RC3
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No

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.

This task depends upon

Comment by Christoph Lipka (clipka) - 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.

Comment by Simon (infoised) - 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?

Comment by Simon (infoised) - 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.

Comment by William F Pokorny (wfpokorny) - Friday, 03 March 2017, 14:37 GMT
  • Field changed: Status (Assigned → Tracked on GitHub)

Now tracked on github as issue #247.

Loading...