Le_Forgeron <jgr### [at] freefr> wrote:
> Le 05/11/2013 22:03, redmasq nous fit lire :
> > I notice with some of my renders that it'll get to 99% and there are a few
> > blocks that are taking their dear sweet time (I've once waited 3 days for the
> > last 200 pixels to finish when the other 99% only took a few hours). Since
> > POV-Ray doesn't support "repartitioning" of the render blocks, I was thinking
> > that could re-render from source those missing blocks albeit with a smaller
> > block size and using the start and end columns to fill in the blanks. Now to the
> > point: does there exist any documentation (beyond the source code) of the
> > pov-state file. My idea was to copy the pov-state file and read the copy with a
> > simple program which will export an image in probably png. Based on behavior
> > seen, I surmise that the file contains a series of blocks that can be "played"
> > to generate the image. If not available, that's okay, I can read the source and
> > write a quickie program, but if someone has already made an effort to at least
> > document, maybe an existing utility... no need to duplicate effort.
> >
> > Thank you in advance.
> >
> >
> It might be easier to read the image on temporary file-buffer (when
> Max_Image_Buffer_Memory option is set low enough): the format is 5 float
> per pixel (R,G,B,F,T), and the tail of the file holds 3 additional
> values, as size_type (integer, local order):
> 1. the size of each pixel := S
> 2. the width of the picture := W
> 3. the height of the picture := H
>
> The number of pixels is rounded up to fit a number of line-block (where
> the size of a line-block in pixel is the size of the rendering block
> along *one* dimension: a 32x32 block size is not using 1024 pixels
> block, but 32 pixel line-blocks)
>
> Pixel for x,y starts at S * (y*W +x) in the file (and ends S bytes later).
> (and obviously, 0<= y < H, and 0 <= x< W)
>
> To know the number of bytes per float, divide S by 5.
> Interpretation of float encoding is: local interpretation (usually
> Ieee-754, but it's the problem of the compiler)
>
> On Unix, the file is created with holes (unwritten part are just 0 and
> do not use filesystem space until the relevant sector/inode is written
> with some values).
> On Windows, the system does not allow such behavior and insists on
> writing all the 0 before continuing and starting the rendering (or even
> the parsing of the scene): better have a fast disk.
>
> The minimal value for Max_Image_Buffer_Memory (to have a file) is 1, as
> 1 megabyte, so the file is used only if the resolution has more than
> 104856 pixels. (bigger than 324 x 324 for a square)
>
> Otherwise, the interesting code for pov-state is in renderfrontend.cpp
> (source/frontend) and povmscpp.h & .cpp (in source/base).
>
> Past the header, there is a sequence of POVMS_Message... some of them
> are rendered blocks, and they have variable geometry, so you cannot just
> jump over some to go where you want: you have to read all of them in
> order. It won't be a fast write of program to handle the various messages.

Thank you, this does help. I found the two files just before reading the
message, so its good to know I was heading in the right direction.  The
explanation of the file format will help me greatly. I had suspected that the
messages had to be read in sequence, the preview window when doing a +C shows
blocks being loaded in original render order. The floats are probably going to
be my biggest problem, there is no way of telling if my compiler will match the
format of the official. There are ways around this, but I'll cross that bridge
when I come to it. I'm hoping that I can just keep a "cursor" and skip any
message that my quickie program doesn't understand. That should be enough for
extracting out the completed block data, shoving it into a buffer, and writing
it to a disk in some random format such as PNG.

On a side note, I remember NTFS supporting sparse file in Windows, although I
believe the application has to do special api call (DeviceIoControl maybe?) on
the file handle or something like that to take advantage of it. Although I would
imagine supporting it would result in an unnecessary headache to the developers.

Post a reply to this message