 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I am using the photo feature now. I recognize, while knowing the initial
creation of the photon map is slow, I still wished there would be some
sort of progress statement, like with the rendering - a percentual or
any update. just to see it goes on. That would work well with the user's
psychology.
Right now, the scene runs for 2 hours, and I still don't know if
everything is okay and there is a progress, or if I did something wrong
and the photon-mapping will never finish. All I see is
"Photon count ()".
And this would be my suggestion: to add some sort of progress info to
the POV-Ray status bar.
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 31.03.2018 um 09:28 schrieb Sven Littkowski:
> I am using the photo feature now. I recognize, while knowing the initial
> creation of the photon map is slow, I still wished there would be some
> sort of progress statement, like with the rendering - a percentual or
> any update. just to see it goes on. That would work well with the user's
> psychology.
>
> Right now, the scene runs for 2 hours, and I still don't know if
> everything is okay and there is a progress, or if I did something wrong
> and the photon-mapping will never finish. All I see is
> "Photon count ()".
>
> And this would be my suggestion: to add some sort of progress info to
> the POV-Ray status bar.
POV-Ray already does exactly that: During photon shooting, the status
bar shows the number of photons shot so far. Updates are shown every 100
photons shot, but at most once a second.
If you don't see photon information in the status bar, either your
photon shooting phase is pathologically fast in its entirety, or
pathologically slow on a per-photon basis.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks.
Now, after 20h 13m 43s, the status bar still shows only
"Photon count ()".
I wonder if it is time to halt it (reminds me to request a new feature.
to continue started photon maps after a stop and not to start from the
begin again, could be done inside the Global Settings Photons Staement with
continue_file "(file name)"
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.04.2018 um 03:47 schrieb Sven Littkowski:
> Thanks.
>
> Now, after 20h 13m 43s, the status bar still shows only
> "Photon count ()".
>
> I wonder if it is time to halt it
Absolutely. At that speed, your photon mapping is going nowhere.
If your scene renders reasonably fast without photons, chances are the
photon setup of your scene has some serious issue(s).
If your scene's main render is as slow as the photon mapping(*), there's
some more egeneral problem with your scene.
(* A lack of photon progress info in 20h is equivalent to POV-Ray not
having completed a single render block even after 8 days(!), presuming
standard 32x32 block size.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks, Clipka.
Based on that experience, it would be my suggestion to add some message
stream feature to POV-Ray that allows better progress control on photon
mapping, or even error checking.
Besides that, I will have to search for the error, but that is at the
moment on a lower priority. I will come back to that (I guess).
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sven Littkowski <I### [at] SvenLittkowski name> wrote:
> Thanks, Clipka.
>
> Based on that experience, it would be my suggestion to add some message
> stream feature to POV-Ray that allows better progress control on photon
> mapping, or even error checking.
Keep in mind that you misconfigured photon mapping really badly: POV-Ray cannot
catch unfortunate user settings very well because it is extremely hard to tell
(basically impossible) if a setting a user selected is intended or a mistake.
What might be a proper setting in one case might be a real mistake in another.
Given every check for progress reporting takes time, the proper cases would be
severely penalized by the time taken to check for the mistakes. The lack of
progress on the other hand is the clear indication that something is wrong. So
you are getting feedback by means of the render time...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <nomail@nomail> wrote:
> Given every check for progress reporting takes time, the proper cases would be
> severely penalized by the time taken to check for the mistakes.
I've thought about this for a number of things POV-Ray does, and I'm sure there
must be some way to toggle a flag to enable or disable such a feature for any
number of things POV-Ray does.
Embedding such a check for a flag may consume more or less cycles depending upon
where the check occurs, and would lead to structuring the source any number of
ways.
Having a dual code where one is "newbie friendly" for extensive debugging would
allow the "advanced/expert version" to run quickly without any such trammels.
Less speedy but easier to code/maintain would be to have whole sets of dual
subroutines that can be selected with such a flag. One slow, but rich in
information and feedback messages, the other optimized for speed.
Sort of the way the quality settings are invoked to do a quick render to make
sure object placement is correct, code in loops is functioning as expected,
etc., and then the highest quality can be set for the final render.
Just an idea for a paradigm to add to the discussion.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Thorsten Froehlich" <nomail@nomail> wrote:
>
> > Given every check for progress reporting takes time, the proper cases would be
> > severely penalized by the time taken to check for the mistakes.
>
> I've thought about this for a number of things POV-Ray does, and I'm sure there
> must be some way to toggle a flag to enable or disable such a feature for any
> number of things POV-Ray does.
>
> Embedding such a check for a flag may consume more or less cycles depending upon
> where the check occurs, and would lead to structuring the source any number of
> ways.
> Just an idea for a paradigm to add to the discussion.
I suppose this would be possible, but adding and maintaining something like that
would not be trivial, assuming you find a developer willing to write it in the
first place.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.04.2018 um 15:28 schrieb Bald Eagle:
> Having a dual code where one is "newbie friendly" for extensive debugging would
> allow the "advanced/expert version" to run quickly without any such trammels.
>
> Less speedy but easier to code/maintain would be to have whole sets of dual
> subroutines that can be selected with such a flag. One slow, but rich in
> information and feedback messages, the other optimized for speed.
Actually no -- quite the opposite: That would be more difficult to maintain.
It would be a comparatively easy job to pepper the source code with
checks that can be turned on or off at compile time, and then build one
binary with the checks and one without.
Having duplicate versions of individual code to be selected at run-time
would introduce a host of challenges and drawbacks:
- It would require some mechanism to branch to one of the two code
variants, introducing extra processing overhead even to the
high-performance path and making the code more difficult to read.
- It would require to actually maintain the two codepaths in source
code; naively, this would mean maintaining two copies of the code,
making sure to port any functional changes between the two, while also
making sure /not/ to port the intentional differences.
- In a less naive approach, the problem of keeping the codepaths in sync
could be greatly simplified by some meta-programming approach, but these
come at a dear cost: Implementing each function as a huge C-style
preprocessor macro would severely "uglify" the code and make debugging
impossible; C++-style templates /can/ be debugged, but only with
difficulty; and using a dedicated meta-programming tool to generate two
separate C++ "source" code files would solve most of the debugging
problems, but make it more complicated to just try out some changes,
while also making the whole project significantly more difficult to
understand for new contributors.
- Either way, it would increase the overhead involved in bug reports:
Most people don't even report the full version number in their first
post; now we'd also need to know what code path they had chosen.
We actually do have some experience with alternate code paths in POV-Ray
chosen at run-time, namely the various optimized noise implementations.
Fortunately, the noise code is comparatively small and very stable, and
has also undergone extensive unit testing by professionals from AMD and
Intel respectively. Otherwise it would probably a maintenance nightmare.
There's also the root solver, which can be switched between sturm and
non-sturm in some primitives. Again, the job of the root solver is
pretty limited in scope and well-defined, and the implementations are
pretty mature.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.04.2018 um 04:48 schrieb Sven Littkowski:
> Based on that experience, it would be my suggestion to add some message
> stream feature to POV-Ray that allows better progress control on photon
> mapping, or even error checking.
How often would you expect feedback? Every 100 photon rays? Every 10?
Each photon?
And what if even that would leave you with 1 minute of no apparent
response? Would you expect even more frequent updates? Each bounce of
the ray, maybe?
No matter how frequent photon progress (or any other progress for that
matter) is reported, there will always be the possibility for
pathological cases where that reporting frequency would not be enough
for a satisfactory user experience.
The way it's currently done is already a trade-off: Getting one report
per second seems like a reasonable frequency; but testing for elapsed
wall-clock time in itself is comparatively time-consuming (after all,
you have to ask the operating system, which means context switching,
which means looooong delays compared to POV-Ray's normal job of
crunching numbers), and we don't want to bog down fast renders with
asking "are we there yet?" after every ray fired.
Counting the rays fired is far easier though, as we don't need the OS
for that. So we count to 1000, and only then do we again ask "are we
there yet?". (*)
As for error checking, what would constitute an error in that context?
We can't anticipate /everything/ that might bog down photon shooting,
and even then it would generally be difficult to draw lines to call it
an error rather than an unfortunate side effect of the quality level
desired by the user.
(* As for some more constructive feedback to your post, I guess it
shouldn't be too much effort to make the "are we there yet" interval
adaptive and essentially use the time measured to make an educated guess
how many rays to count before asking again.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
