with possibly large implications.

A commandline (I run linux) option to disable the pov-state file.

Why?

I render multiple test runs for an animation and all frames get stored on a 
network, so the pov-state file gets stored on that same network. 
I understand the value of the pov-state file because it allows one to 
continue a render from whatever point in case of a mishap.
In my case, I'll simply restart the render at 1 frame before the mishap.


ps, I'm not a programmer so I don't know how involved a change like that 
could turn out to be.
-- 
Ger

Post a reply to this message

Am 17.12.2013 09:00, schrieb Ger:
> with possibly large implications.
>
> A commandline (I run linux) option to disable the pov-state file.
>
> Why?
>
> I render multiple test runs for an animation and all frames get stored on a
> network, so the pov-state file gets stored on that same network.
> I understand the value of the pov-state file because it allows one to
> continue a render from whatever point in case of a mishap.
> In my case, I'll simply restart the render at 1 frame before the mishap.

Sounds like a reasonable request to me.

> ps, I'm not a programmer so I don't know how involved a change like that
> could turn out to be.

A quick glance at the code indicates that someone had already thought of 
this, and all the necessary stuff seems to be there already, except that 
it hasn't been hooked up to a command line option or ini file setting 
yet. Two lines of code should get us going.

Suggestions for how to call the thing, anyone? Internally it is called 
"BackupTrace", and it complements the existing "Continue_Trace" option 
("+C", internally "ContinueTrace), so a suitable ini setting name might 
be "Backup_Trace" (defaulting to true); the "+B" switch is already in 
use though; "-BC" ("[disable] backup for +C") or "-CB" ("[disable] +C 
backup") would still be open.

Post a reply to this message

clipka wrote:

> Am 17.12.2013 09:00, schrieb Ger:
>> with possibly large implications.
>>
>> A commandline (I run linux) option to disable the pov-state file.
>>
>> Why?
>>
>> I render multiple test runs for an animation and all frames get stored on
>> a network, so the pov-state file gets stored on that same network.
>> I understand the value of the pov-state file because it allows one to
>> continue a render from whatever point in case of a mishap.
>> In my case, I'll simply restart the render at 1 frame before the mishap.
> 
> Sounds like a reasonable request to me.
> 
>> ps, I'm not a programmer so I don't know how involved a change like that
>> could turn out to be.
> 
> A quick glance at the code indicates that someone had already thought of
> this, and all the necessary stuff seems to be there already, except that
> it hasn't been hooked up to a command line option or ini file setting
> yet. Two lines of code should get us going.
> 
> Suggestions for how to call the thing, anyone? Internally it is called
> "BackupTrace", and it complements the existing "Continue_Trace" option
> ("+C", internally "ContinueTrace), so a suitable ini setting name might
> be "Backup_Trace" (defaulting to true); the "+B" switch is already in
> use though; "-BC" ("[disable] backup for +C") or "-CB" ("[disable] +C
> backup") would still be open.

Maybe

+PS (default) turns it on, -PS turns it off.

Just a suggestion.

-- 
Ger

Post a reply to this message

Ger wrote:


> 
> Maybe
> 
> +PS (default) turns it on, -PS turns it off.

ini file:
pov_state=[on/true/yes][off/false/no]
> 
> Just a suggestion.
> 


-- 
Ger

Post a reply to this message

Le 17/12/2013 09:35, clipka a écrit :
> Am 17.12.2013 09:00, schrieb Ger:
>> with possibly large implications.
>>
>> A commandline (I run linux) option to disable the pov-state file.
>>
>> Why?
>>
>> I render multiple test runs for an animation and all frames get stored
>> on a
>> network, so the pov-state file gets stored on that same network.
>> I understand the value of the pov-state file because it allows one to
>> continue a render from whatever point in case of a mishap.
>> In my case, I'll simply restart the render at 1 frame before the mishap.
> 
> Sounds like a reasonable request to me.
> 
>> ps, I'm not a programmer so I don't know how involved a change like that
>> could turn out to be.
> 
> A quick glance at the code indicates that someone had already thought of
> this, and all the necessary stuff seems to be there already, except that
> it hasn't been hooked up to a command line option or ini file setting
> yet. Two lines of code should get us going.
> 
> Suggestions for how to call the thing, anyone? Internally it is called
> "BackupTrace", and it complements the existing "Continue_Trace" option
> ("+C", internally "ContinueTrace), so a suitable ini setting name might
> be "Backup_Trace" (defaulting to true); the "+B" switch is already in
> use though; "-BC" ("[disable] backup for +C") or "-CB" ("[disable] +C
> backup") would still be open.
> 

The purpose of the pov-state is to allow for "+C"/continue. So what
about: "Disable_Continue" , "NoContinue" ("+NC" to have no saved data),
+SH (Sledge Hammer: "Trust me I know what I'm doing") ?

Or extending +C, such as:
 +C continue
 -C no continue
 +C0 no backup for ulterior continue
 +C1 backup for ulterior continue

I did not check about the availability of the names.
-- 
Just because nobody complains does not mean all parachutes are perfect.

Post a reply to this message

Am 17.12.2013 10:57, schrieb Le_Forgeron:

> The purpose of the pov-state is to allow for "+C"/continue. So what
> about: "Disable_Continue" , "NoContinue" ("+NC" to have no saved data),
> +SH (Sledge Hammer: "Trust me I know what I'm doing") ?

Rather not; the general convention is that a feature is enabled with 
"+FOO" and disabled with "-FOO", rather than enabled with "-NFOO" and 
disabled with "+NFOO". Note that the feature in question here is the 
ability to pick up an aborted render later with the "+C" switch - the 
inverse logic can only be formulated as the suppression of that feature 
to avoid the costs it imposes, so it isn't a feature in itself.


> Or extending +C, such as:
>   +C continue
>   -C no continue
>   +C0 no backup for ulterior continue
>   +C1 backup for ulterior continue

Magic numbers and mixing with the other switch? Uh, no please.

Again, note the generic convention for enabling and disabling features, 
which use leading "+" and "-" to insicate whether a certain feature is 
to be enabled or disabled; let's not mess this up by giving similar 
semantics to trailing numbers.


Also, let's not try to force two distinct choices, to be made in two 
entirely distinct situations, into one and the same command switch.

There is one choice to be made by the user whether he wants to be able 
to abort the render, so that he /may/ continue it later. This choice 
must be made /before/ a render is aborted.

There is another choice to be made by the user whether he wants to 
continue a previously aborted render, or restart from scratch. This 
choice must be made /after/ a render is aborted.

Although the features interact, the choices are clearly distinct, and 
made in different situations, so there should be distinct ways of 
communicating these choices to POV-Ray.

Post a reply to this message

On 17/12/13 08:35, clipka wrote:
[...]
> A quick glance at the code indicates that someone had already thought of
> this, and all the necessary stuff seems to be there already, except that
> it hasn't been hooked up to a command line option or ini file setting
> yet. Two lines of code should get us going.

Is there a way to specify the location? There's value in having the
pov-state file written to a different directory to the output file ---
for example, a local drive rather than a network drive in the OP's case.
It would then be trivial to extend to 'write nowhere'.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom

Post a reply to this message

Am 17.12.2013 13:36, schrieb David Given:
> On 17/12/13 08:35, clipka wrote:
> [...]
>> A quick glance at the code indicates that someone had already thought of
>> this, and all the necessary stuff seems to be there already, except that
>> it hasn't been hooked up to a command line option or ini file setting
>> yet. Two lines of code should get us going.
>
> Is there a way to specify the location? There's value in having the
> pov-state file written to a different directory to the output file ---
> for example, a local drive rather than a network drive in the OP's case.
> It would then be trivial to extend to 'write nowhere'.

As I said, the "write nowhere" feature is already there behind the 
curtains, it's just not exposed via a command line switch yet. 
Implementing a way to write to a different directory would need more effort.

Post a reply to this message

Le 17/12/2013 15:36, clipka a écrit :
> Am 17.12.2013 13:36, schrieb David Given:
>> On 17/12/13 08:35, clipka wrote:
>> [...]
>>> A quick glance at the code indicates that someone had already thought of
>>> this, and all the necessary stuff seems to be there already, except that
>>> it hasn't been hooked up to a command line option or ini file setting
>>> yet. Two lines of code should get us going.
>>
>> Is there a way to specify the location? There's value in having the
>> pov-state file written to a different directory to the output file ---
>> for example, a local drive rather than a network drive in the OP's case.
>> It would then be trivial to extend to 'write nowhere'.
> 
> As I said, the "write nowhere" feature is already there behind the
> curtains, it's just not exposed via a command line switch yet.
> Implementing a way to write to a different directory would need more
> effort.
> 

about the entry: what about
+AC / -AC : Allow_Continue = true/false ?

(because I prefer to see it as a functionality rather than a technical
details: should the pov.state file mechanism be changed for something
else, the +C would still be the command to use to continue an aborted
render)

Looking at available options, B is parameterless, BM & BS exist.
C is parameterless and alone, so BT , CT and other are possible.

From the option name: BT (BackupTrace) seems natural.
Yet, I would prefer AC (and it is possible too).


-- 
Just because nobody complains does not mean all parachutes are perfect.

Post a reply to this message

On 12/17/2013 02:00 AM, Ger wrote:
> with possibly large implications.
>

Using the chainsaw approach I cut out all code that had to do with 
BackupTrace, ContinueTrace and Pov_state and all that fun, I have a 
working pov version (dunno how working yet) that doesn't bs around with 
pov-state files and produces the results I do like.
And if anyone would like for me to post the resulting code, rest 
assured, I won't post it. The chances for it to eat your children and/or 
your in-laws is just too great.

Post a reply to this message