Hey guys!

I've been trying to figure out exactly how the resume (or continue, +C) feature
works in 3.7 RC6.  Whenever I try to resume, it either sits there with no output
(after === [Rendering...] ===) or it sits there with the output "Rendered 1024
of 14700000 pixels" (I'm rendering a 1400 x 1050 image).  Yes, I paused at a
stage where every step takes a long time, but I'm confused by the output.  Is it
actually resuming?  It says "Continued trace......On", so I would assume so.
But then, why doesn't it resume the "Rendered" counter where it left off?

Thanks in advance!

- Chaanakya

Post a reply to this message

> Hey guys!
>
> I've been trying to figure out exactly how the resume (or continue, +C) feature
> works in 3.7 RC6.  Whenever I try to resume, it either sits there with no output
> (after === [Rendering...] ===) or it sits there with the output "Rendered 1024
> of 14700000 pixels" (I'm rendering a 1400 x 1050 image).  Yes, I paused at a
> stage where every step takes a long time, but I'm confused by the output.  Is it
> actually resuming?  It says "Continued trace......On", so I would assume so.
> But then, why doesn't it resume the "Rendered" counter where it left off?
>
> Thanks in advance!
>
> - Chaanakya
>
>

It does effectively resume the render where it was interupted.
The pixel count don't take into acount the part of the image that was 
done, only the part to be done. If the bit of the image is one that take 
a LOT of time, it will look as if it's gone into limbo, but it's still 
working and will eventualy show some progress.

When resuming, you need to access the *.povstate file, that may be very 
large and take some time to process, and re-parse the source file. If 
the parse was long, it will take that same time every time you resume.
If the scene use radiosity, the pre trace step will be repeated, but 
only for the part not yet rendered.
I've not yet resumed a photons scene.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
> Le 8/21/2012 3:28 PM, Chaanakya a écrit :
> > Hey guys!
> >
> > I've been trying to figure out exactly how the resume (or continue, +C) feature
> > works in 3.7 RC6.  Whenever I try to resume, it either sits there with no output
> > (after === [Rendering...] ===) or it sits there with the output "Rendered 1024
> > of 14700000 pixels" (I'm rendering a 1400 x 1050 image).  Yes, I paused at a
> > stage where every step takes a long time, but I'm confused by the output.  Is it
> > actually resuming?  It says "Continued trace......On", so I would assume so.
> > But then, why doesn't it resume the "Rendered" counter where it left off?
> >
> > Thanks in advance!
> >
> > - Chaanakya
> >
> >
>
> It does effectively resume the render where it was interupted.
> The pixel count don't take into acount the part of the image that was
> done, only the part to be done. If the bit of the image is one that take
> a LOT of time, it will look as if it's gone into limbo, but it's still
> working and will eventualy show some progress.
>
> When resuming, you need to access the *.povstate file, that may be very
> large and take some time to process, and re-parse the source file. If
> the parse was long, it will take that same time every time you resume.
> If the scene use radiosity, the pre trace step will be repeated, but
> only for the part not yet rendered.
> I've not yet resumed a photons scene.

Alright.  Thanks for the info! :)

Post a reply to this message

"Chaanakya" <nomail@nomail> wrote:
> Alain <kua### [at] videotronca> wrote:
> > Le 8/21/2012 3:28 PM, Chaanakya a écrit :
> > > Hey guys!
> > >
> > > I've been trying to figure out exactly how the resume (or continue, +C) feature
> > > works in 3.7 RC6.  Whenever I try to resume, it either sits there with no output
> > > (after === [Rendering...] ===) or it sits there with the output "Rendered 1024
> > > of 14700000 pixels" (I'm rendering a 1400 x 1050 image).  Yes, I paused at a
> > > stage where every step takes a long time, but I'm confused by the output.  Is it
> > > actually resuming?  It says "Continued trace......On", so I would assume so.
> > > But then, why doesn't it resume the "Rendered" counter where it left off?
> > >
> > > Thanks in advance!
> > >
> > > - Chaanakya
> > >
> > >
> >
> > It does effectively resume the render where it was interupted.
> > The pixel count don't take into acount the part of the image that was
> > done, only the part to be done. If the bit of the image is one that take
> > a LOT of time, it will look as if it's gone into limbo, but it's still
> > working and will eventualy show some progress.
> >
> > When resuming, you need to access the *.povstate file, that may be very
> > large and take some time to process, and re-parse the source file. If
> > the parse was long, it will take that same time every time you resume.
> > If the scene use radiosity, the pre trace step will be repeated, but
> > only for the part not yet rendered.
> > I've not yet resumed a photons scene.
>
> Alright.  Thanks for the info! :)

All what Alain said is correct completely. But I have some additional
suggestions.

If you intend to suspend POV, may be because you need your machine for other
purposes, you first should consider the STOP-button (if you have a windows os,
I'm not quiet sure about it on mac or linux, but I think to remember that the
editor which comes with the windows version is not available with mac os or
linux. But may be I'm be wrong with this). That will freeze POV and give you the
machine back but I assume that it doesn't swap the allocated memory by POV.

As with version 3.7 the saving of radiosity data is not supported within the
code as it was up to version 3.6. You can obtain this still over the command
line options. With the windows version you can add such options easily within
the field right to the resolutions, which is blank by default.

If you possess a machine with more than one thread another idea is to limit the
threads POV uses. For example, if you need your machine for some more simple
programs like MS Word or Excel and you have a Core i7 with 8 threads you can
type +WT6 in the command line field I mentioned above and have POV running and
may be enough resources for other tasks (the allocated memory is still an isuue
but may be it works. For axample: My picture "The tale of the magpie and the
diamond cuckoo" which I posted some days ago to the p.b.i. (look for "texturing
the orlov diamond..."), took with the raised max_trace_level 14 days to render,
but with +WT6 I was able to use the machine for other purposes without any
inconvience).

I'm still investigating this proton issue since I have a good reference picture
handy but it renders a while. You can save protons and load them. They are
stored after the proton pass immediately, so I expect that if you have once gone
throught this pass you can load them in a +C attempt without the need to
recompute them.

Best regards so far
Michael

Post a reply to this message

On 22/08/2012 7:52 PM, MichaelJF wrote:

>
> All what Alain said is correct completely. But I have some additional
> suggestions.
>
> If you intend to suspend POV...

I regularly resume Pov because I start rendering a scene from a modeller 
that does not support Ver 3.7. I will stop the render make changes then 
resume it. My most common change is to the INI file where I add the line 
Render_Block_Size=8
I feel that this speeds up the render at the end when I have 7 cores 
idle waiting on the last core to render a 32 by 32 block.

-- 
Regards
     Stephen

Post a reply to this message

Le 22/08/2012 22:51, Stephen a écrit :
> My most common change is to the INI file where I add the line
> Render_Block_Size=8
> I feel that this speeds up the render at the end when I have 7 cores
> idle waiting on the last core to render a 32 by 32 block.


If the Render_Block_Size is only an addition (not a change of value from
the ini file), and you are on a Unix port, what about setting it in your
$HOME/.povray/3.7/povray.ini ?
(On the windows port, it's kind of "MAster povray.ini" in Tools sub menu)

Comments (0.01€) about reducing the block size: it might be quicker in
the end, but it comes with an increased communication between the
rendering threads and the "storage" thread. Instead of 1 messages for
32x32, a 8x8 will generates 16 messages ( (32/8)^2 ).


(There is no perfect value: too small gives a large overhead of message
with fine granularity, too large gives less overhead but coarser
granularity with numerous cores. Choose your own balance: if it please
you, it's the right value)

Post a reply to this message

On 22-8-2012 20:52, MichaelJF wrote:
> If you possess a machine with more than one thread another idea is to limit the
> threads POV uses. For example, if you need your machine for some more simple
> programs like MS Word or Excel and you have a Core i7 with 8 threads you can
> type +WT6 in the command line field I mentioned above and have POV running and
> may be enough resources for other tasks (the allocated memory is still an isuue
> but may be it works. For axample: My picture "The tale of the magpie and the
> diamond cuckoo" which I posted some days ago to the p.b.i. (look for "texturing
> the orlov diamond..."), took with the raised max_trace_level 14 days to render,
> but with +WT6 I was able to use the machine for other purposes without any
> inconvience).

Yes, I agree, and I use this also with my i7 machine. In addition, be 
aware of the following issue when rendering with radiosity on in a 
multi-core machine: the different threads are not released in order but 
when they finish their task. This results in isolated blocks being 
rendered within finished fields on the image. When stopping a render to 
start it again later, be sure to verify first that all finished rendered 
threads are consecutive, i.e. that there are *no* isolated unfinished 
threads in the image. When starting up render again (+C) rendering is 
started from the /last/ finished block; all isolated unfinished blocks 
are ignored and are shown as such in the image.

I hope I have made myself clear...

Thomas

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Comments (0.01€) about reducing the block size: it might be quicker in
> the end, but it comes with an increased communication between the
> rendering threads and the "storage" thread. Instead of 1 messages for
> 32x32, a 8x8 will generates 16 messages ( (32/8)^2 ).

Yes, I feared for that. Especially using features like anti aliasing there must
be some communication between the threads. But with images which have very long
rendering times it is a psychological advantage to use +BS8, since you see a
progress once in a while.

And yes Thomas, you have made yourself clear, I have observed this behaviour
too. Has someone tried to resume with saved radiosity data? May be the old
trick, to render a small picture and saving the radiosity for a rendering with a
higher resolution will help. But I think POV starts simply at the last completed
block overlooking the fact that some earlier ones are missing.

In the meantime I have tested the photon issue and got very strange results with
the picture of the (clumsy model of the) sceptre of Catherine the Great. Using a
simple sky_sphere, there were no problems but with my attempt to use an HDRI
lighting (which can be a wrong parametrisation by me since it is the first time
I tried such a lighting) I observed strange changes in color. I will put the
images in the p.b.i. for further discussion soon.

Best regards,
Michael

Post a reply to this message

On 23/08/2012 7:45 AM, Le_Forgeron wrote:
> (There is no perfect value: too small gives a large overhead of message
> with fine granularity, too large gives less overhead but coarser
> granularity with numerous cores. Choose your own balance: if it please
> you, it's the right value)

Normally I go with the default block size but if I end up waiting for 
the last block to finish I will change subsequent renders.
I did some quick tests on random scenes and confirmed that you are 
right, lowering the block size can increase the time taken.


-- 
Regards
     Stephen

Post a reply to this message