On 6/4/2017 3:59 AM, Alain wrote:
> Le 17-06-01 à 04:47, Stephen a écrit :
>> On 6/1/2017 8:30 AM, Mr wrote:
>>> and not be deleted until image is
>>> fully rendered, (or the whole animation?). that way, if you turn off
>>> your
>>> computer and start rendering again from empty pov editor with "+C"
>>> the scene
>>> will just go on rendering.
>>>
>>> Am I correct so far guys?
>>>
>>
>> On all of the Windoze machines I've had. The state file is not always
>> deleted.
>
> It's always deleted once the render finishes normally.
>
>

It was only an observation not a complaint. I've noticed it when I clean 
up my hard drives. I've not formally tested this.

-- 

Regards
     Stephen

Post a reply to this message

Am 03.06.2017 um 02:58 schrieb omniverse:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 02.06.2017 um 00:20 schrieb omniverse:
>>
>>> However, I thought maybe I could remove the last portion of the state file and
>>> still be able to continue a render that way. Idea being that if all it does is
>>> append each render block info, and the last one was incomplete or corrupt, maybe
>>> deleting back to the last complete good block would let it be usable again.
>>>
>>> Well, no good. At least if simply editing in Notepad. Yet it is obvious, or so I
>>> believe, where the blocks seem to begin and end. This is something like the end
>>> of a good state file:
>>
>> Notepad is not a good choice to try this. The data is binary, and I'd be
>> surprised if Notepad kept any binary data intact.
> 
> Figured it was a bad idea. Way back when I used Windows Write to change text
> within programs that was usually okay, but only if I didn't touch anything else
> not ever having learned C programming.
> 
> I installed a file code editor and got same result anyway when deleting back to
> prior ViIdINT4, which is what I'm seeing a good state file always ends with.

What exactly do you mean by "file code editor"? A text editor you'd use
for writing program code?

That would generally be of no use either.

You should really use a hex editor for such manipulations.


I've had a look at the relevant source code by now, and judging from it
there should be no problem reading a truncated file: The code is
designed to just read the state file up to the first location that
doesn't seem to make sense.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 03.06.2017 um 02:58 schrieb omniverse:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Am 02.06.2017 um 00:20 schrieb omniverse:
> >>
> >>> However, I thought maybe I could remove the last portion of the state file and
> >>> still be able to continue a render that way. Idea being that if all it does is
> >>> append each render block info, and the last one was incomplete or corrupt, maybe
> >>> deleting back to the last complete good block would let it be usable again.
> >>>
> >>> Well, no good. At least if simply editing in Notepad. Yet it is obvious, or so I
> >>> believe, where the blocks seem to begin and end. This is something like the end
> >>> of a good state file:
> >>
> >> Notepad is not a good choice to try this. The data is binary, and I'd be
> >> surprised if Notepad kept any binary data intact.
> >
> > Figured it was a bad idea. Way back when I used Windows Write to change text
> > within programs that was usually okay, but only if I didn't touch anything else
> > not ever having learned C programming.
> >
> > I installed a file code editor and got same result anyway when deleting back to
> > prior ViIdINT4, which is what I'm seeing a good state file always ends with.
>
> What exactly do you mean by "file code editor"? A text editor you'd use
> for writing program code?

Code Writer from Actipro.

> That would generally be of no use either.
>
> You should really use a hex editor for such manipulations.

Been without a hex editor for years, and years. Thanks for pointing me in the
right direction!

Tried that now using HxD (https://mh-nexus.de/en/), and that does work okay if
deleting back from end of file to the prior ViIdINT4.
Or more precisely, as seen in the Hex editor:

56 69 49 64 49 4E 54 34 00 00 00 04 00 00 00 03

 or

ViIdINT4........

> I've had a look at the relevant source code by now, and judging from it
> there should be no problem reading a truncated file: The code is
> designed to just read the state file up to the first location that
> doesn't seem to make sense.

No luck here when I deleted back to a midway point between the ViIdINT4's.
POV-Ray just acts like the render was done without opening a render window and
doesn't show any errors in the message pane.

Bob

Post a reply to this message

Am 05.06.2017 um 13:19 schrieb omniverse:

> Tried that now using HxD (https://mh-nexus.de/en/), and that does work okay if
> deleting back from end of file to the prior ViIdINT4.
> Or more precisely, as seen in the Hex editor:
> 
> 56 69 49 64 49 4E 54 34 00 00 00 04 00 00 00 03
> 
>  or
> 
> ViIdINT4........

Yes, those "00", "04" and "03" are characters you're typically losing if
you use any odd text editor.

>> I've had a look at the relevant source code by now, and judging from it
>> there should be no problem reading a truncated file: The code is
>> designed to just read the state file up to the first location that
>> doesn't seem to make sense.
> 
> No luck here when I deleted back to a midway point between the ViIdINT4's.
> POV-Ray just acts like the render was done without opening a render window and
> doesn't show any errors in the message pane.

Does that hold true even if you do the truncation in a hex editor?

Because the file is full of "00" and other non-printable characters, and
text editors tend to not treat them nicely.

Also, the file is likely to include some "0D" here and there, which a
Windows-based text editor might interpret as a Unix-style line ending
and replace it with the Windows-style "0D 0A" line ending when saving;
while a Unix-based text editor might do just the opposite, replacing any
occurrence of "0D 0A" with "0D". Either modification will invariably
break the file from that point onward.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 05.06.2017 um 13:19 schrieb omniverse:
>
> > Tried that now using HxD (https://mh-nexus.de/en/), and that does work okay if
> > deleting back from end of file to the prior ViIdINT4.
> > Or more precisely, as seen in the Hex editor:
> >
> > 56 69 49 64 49 4E 54 34 00 00 00 04 00 00 00 03
> >
> >  or
> >
> > ViIdINT4........
>
> Yes, those "00", "04" and "03" are characters you're typically losing if
> you use any odd text editor.
>
> >> I've had a look at the relevant source code by now, and judging from it
> >> there should be no problem reading a truncated file: The code is
> >> designed to just read the state file up to the first location that
> >> doesn't seem to make sense.
> >
> > No luck here when I deleted back to a midway point between the ViIdINT4's.
> > POV-Ray just acts like the render was done without opening a render window and
> > doesn't show any errors in the message pane.
>
> Does that hold true even if you do the truncation in a hex editor?
>
> Because the file is full of "00" and other non-printable characters, and
> text editors tend to not treat them nicely.
>
> Also, the file is likely to include some "0D" here and there, which a
> Windows-based text editor might interpret as a Unix-style line ending
> and replace it with the Windows-style "0D 0A" line ending when saving;
> while a Unix-based text editor might do just the opposite, replacing any
> occurrence of "0D 0A" with "0D". Either modification will invariably
> break the file from that point onward.

No changes like that showing up in hex editor.

Could be my mistake about the messages POV-Ray shows, I guess. I might have
overlooked a regular kind of message because I had been thinking it would be
highlighted or look more obvious.

I was trying the same thing as before by removing the last good block of code
back to ViIdINT4 (plus extraneous code afterward as I already told of). Got the
same no render window again.
However this time I noticed the message pane tells me it was "skipped" because
it already existed (shows message near end of all other info). Sure enough, the
completed render was there so I deleted it.

Next I removed code back to a midway point of end to ViIdINT4.....

Successful with continue trace (without existing image), it draws up the
partially done render window and goes on to finish it.

Only difference this time is the 03's are now 02's, which I couldn't explain.
Maybe relates to different day?? Only conjecture I'm sure.

Bob

Post a reply to this message

Am 06.06.2017 um 00:41 schrieb omniverse:

> Only difference this time is the 03's are now 02's, which I couldn't explain.
> Maybe relates to different day?? Only conjecture I'm sure.

I'd expect the value to depend directly on how many renders you've run
earlier during the same POV-Ray session.

Post a reply to this message

"clipka" <nomail@nomail> wrote:

> If the power outage strikes at a time where POV-Ray is just updating the state
> file, there might be a possibility that the state file gets corrupted; I've
> never had a look how robust POV-Ray's abort-continue mechanism would be with
> respect to a truncated state file.

In all systems, it's possible to write a script that periodically saves the
state file periodically.

Post a reply to this message