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