Reworking renderer statistics

[Omniflux]

Omniflux, is it possible to exclude an eye pass duration from the interval?

I don't know what an eye pass is, and a few minutes of googling has not enlightened me; unless it is only done once at the beginning, I do not see how doing this would makes sense.

[J the Ninja]

Omniflux, is it possible to exclude an eye pass duration from the interval?

I don't know what an eye pass is, and a few minutes of googling has not enlightened me; unless it is only done once at the beginning, I do not see how doing this would makes sense.

SPPM specific thing:

In a nutshell, the way SPPM works is like traditional photon mapping, except backwards and repeated over and over. The first half of each pass is the eye pass, where it fires rays from the eye and bounces them until they land on a diffuse surface. Once that happens, you drop a "hitpoint" (like a photon, but from the eye instead of a light source). The second half is the photon pass, where you fire photons from the lights out into the scene, and see which hit points they fall within a specified radius of. If they fall into a hitpoint, that hitpoint is considered to have been illuminated by that light. Then what you reach a predetermined number of photons (not sure if its photons fired or photons gathered), you end the pass, throw out the hitpoint map, and start over and each time that hitpoint radius gets smaller.


So photons/sec only counts photons fired from the lights, which are only going out during the photon half of the pass. If you count photons/sec the entire time, Lux thinks you are encountering some slow down in photon shooting when in reality you are just in a stage of the render where you don't fire any.

[Omniflux]

Should there be an eye rays per second statistic as well then?

What should be happening to the photons / sec statistic during the eye pass? holds the last value? this would be odd because then the number of photons is not increasing even though photons / sec is non zero.

[cwichura]

There seems to be a new problem with the estimation of network slaves in the latest weekly (where the new slave code to pull resources from the master was introduced). If you look at the attached screenshot, the estimated slave progress is LESS than the actual samples received from the slave. And while you can't see the log tab in that screenshot, it has been over two hours since samples were last fetched from the slave when this screenshot was taken. This render has been consistently like this since it was started. The estimated slave samples per pixel has always been less than the actual samples per pixel retrieved as shown by the network tab.

The kS/s seems to be about right, however. The slave in use is a bit more than twice as fast as the master. (The abysmal performance on this render is due to the rather nice Forest environment recently released at DAZ3D, which has massive amounts of transmap'd leaves, grass, etc in it. Usually my render speeds are 3-4 times what this scene is achieving.)

[B.Y.O.B.]

An idea for the SPPM statistics: average Eye pass/Photon pass times. What do you think about that? Would it be useful to add them to the statistics?

[A-man]

An idea for the SPPM statistics: average Eye pass/Photon pass times. What do you think about that? Would it be useful to add them to the statistics?

These times change as the radius reduces, fex it might take 2 minutes for your first pass, and 10 seconds for your 10000th pass. It wouldn't be useful to compare different computers, but it still might be interesting to have anyways.

[B.Y.O.B.]

Ok, if the times decrease over time, it wouldn't be of much use to have an average of them in the statistics.
The idea just came to me as I always watch the log when using SPPM, to check if I should change the amount of photons per pass or the starting radius.

[SATtva]

Is everything's alright with stats rounding? Once again it fluctuates heavily -- on my Spheres scene it jumps like crazy between 43 and 50 kS/s, and kC/s range is even bigger due to high %Eff.