 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] free fr> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.11.2013 00:01, schrieb redmasq:
> 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.
Maybe not entirely unnecessary, but at least additional headache.
Still, I'd suggest to file a feature request on http://bugs.povray.org.
If you could also find the time to figure out the necessary API calls,
that would of course be a great help to the developers ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
>
>
>
>
Sparse files are not "new" in any way...
The first time I read about sparse files was way before the creation of
NTFS. It dates back to when I was using my Apple ][+ and Apple DOS 3.3.
Even back then, it was possible to create a file that, if not sparse,
could weight at a few Mb on a floppy that had a capacity of less than
400 Kb.
I even created a few with some small programms writen in Basic.
I would'nt be surprised if it was possible in even the early verions of
MS-DOS under the FAT12 file system... After all, Apple DOS was writen my
Microsoft a few years before the first PCs.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 09.11.2013 19:20, schrieb Alain:
> The first time I read about sparse files was way before the creation of
> NTFS. It dates back to when I was using my Apple ][+ and Apple DOS 3.3.
> Even back then, it was possible to create a file that, if not sparse,
> could weight at a few Mb on a floppy that had a capacity of less than
> 400 Kb.
> I even created a few with some small programms writen in Basic.
>
> I would'nt be surprised if it was possible in even the early verions of
> MS-DOS under the FAT12 file system... After all, Apple DOS was writen my
> Microsoft a few years before the first PCs.
No, not really. Apple DOS was written by Steve Wozniak, i.e. Apple.
Bill Gates & Co. never had anything to do with it. They were CP/M
jockeys, and MS-DOS was based on that one. It never had system calls for
sparse files handling, nor did the FAT file system specify any way to
support them in the first place.
Microsoft even developed a Z80 processor extension card for the Apple
II, in order to open the Apple II software market for their CP/M based
products (CP/M being exclusive to Z80-based architectures).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
