On 2/27/25 16:58, William F Pokorny wrote:
> Try adding, instead, the string 'rerun' the next time you try to resume 
> an interrupted render

Real life always seems to keep me busy in late February and March...

While sitting in a waiting room this morning, the storm in my head asked 
me what happens on the second use of rerun.ini where both 
'create_ini=rerun.ini' and 'include_ini=rerun.ini' are present.

Is the code smart enough to not get into a recursive 'include 
ini=rerun.ini'. descent.

I'm going to look for a slice of time to experiment a little with a 
dummy animation where I quit and continue(*) frames...

Bill P.

(*) - continue.ini is a better name  when you are continuing a render... 
This is all stuff in the windows interface and render continuations that 
I don't do regularly. It might be I'm mostly clueless.

Post a reply to this message

On 2/28/25 18:13, William F Pokorny wrote:
> Is the code smart enough to not get into a recursive 'include 
> ini=rerun.ini'. descent.

The answer is, no, where a user creates something like this in an ini file:

...
Continue_Trace=On
Create_Ini="continue.ini"
...
include_ini="continue.ini"
...

we get recursive inclusion of the continue.ini file.

To POV-Ray's credit, in all versions of POV-Ray I have in hand, the 
recursion does eventually stop and we get a vague parse error. I believe 
the general recursion depth limit for including files stops things from 
getting too out of control.

--

We can specify continue.ini on the command line - without triggering 
recursive inclusion - with any of:

povray include_ini=continue.ini
povray continue.ini
povray continue

POV-Ray does not write any include_ini="continue.ini" equivalent into 
the continue.ini file when it is specified on the command line. In other 
words, it avoids creating a recursive inclusion of the ini file in the 
saved options file.

Speaking of the create_ini= / +gi option; Unsure about the how robust it 
is in v3.7, but in v3.8 versions (including yuqk) be sure it is 
capturing all the settings you need to capture to re-run or continue a 
render. I've never done a survey of all the options, but I know for 
example, file_gamma= and display_gamma= are NOT captured with v3.8 
versions and they should be.

In a few hours of testing I picked up a handful of other small details 
which I've added to my documentation, but I believe the advice given 
previously is mostly OK. On linux/unix at least, the continue / resume 
features look to be working well with all the v3.7, v3.8 and v3.8 (yuqk) 
versions I tested.

You can in fact skip using create_ini= / +gi if you are otherwise sure 
options are not changing. With v3.7 this means rendering with +c. In 
v3.8 versions it means rendering with +c and +cc (though +cc might not 
be the smart choice where per frame render times are short).

Bill P.

Post a reply to this message

On 2/28/25 21:01, William F Pokorny wrote:
> In a few hours of testing I picked up a handful of other small details 
> which I've added to my documentation,

A few years ago Thomas picked up an issue with continued renders and 
radiosity (*). I wanted to add an issues note to my documentation for 
that so I was searching the newsgroups.

I stumbled across this comment by Christoph Hormann from October of 2001 
in a thread about continuing radiosity renders:

"At least in WinPov, the .rca gets deleted when you press 'stop'. The 
only way to maintain it is to actually kill povray while rendering. ;-)"

The .rca-file being the .pov-state filename at the time.

I don't run windows so I cannot test if this is still true. FWIW.

Bill P.

(*) - You need to use save and load radiosity samples to avoid 
radiosity{} discontinuities when continuing or setting up to continue 
renders of scenes using radiosity{}.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/28/25 21:01, William F Pokorny wrote:
> > In a few hours of testing I picked up a handful of other small details
> > which I've added to my documentation,
>
> A few years ago Thomas picked up an issue with continued renders and
> radiosity (*). I wanted to add an issues note to my documentation for
> that so I was searching the newsgroups.
>
> I stumbled across this comment by Christoph Hormann from October of 2001
> in a thread about continuing radiosity renders:
>
> "At least in WinPov, the .rca gets deleted when you press 'stop'. The
> only way to maintain it is to actually kill povray while rendering. ;-)"
>
> The .rca-file being the .pov-state filename at the time.
>
> I don't run windows so I cannot test if this is still true. FWIW.
>
> Bill P.
>
> (*) - You need to use save and load radiosity samples to avoid
> radiosity{} discontinuities when continuing or setting up to continue
> renders of scenes using radiosity{}.

From my poor memory, Last time I used it, I think it worked also with straight
stopping, but this was before the povwin code got clearly split and optional.The
issue I had met with radiosity was that some buckets of the image probably got
different rays averaged together so they created small artifact, but the
continue feature could still be considered usable because post render edit would
easily solve those.

Post a reply to this message