 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
We are trying to implement partial output (border render) into blender's
exporter.
What happens is that we got it working except opening the output image crashes
blender. I suppose it's due to this fact mentioned in povray doc:
"""
When rendering a subset of *rows* (+sr/+er) POV-Ray writes the full height into
the image file header and only writes those lines into the image that are
rendered. This can cause problems with image reading programs that are not
checking the file while reading and just read over the end.
If POV-Ray wrote the actual height of the partial image into the image header
there would be no way to continue the trace in a later run.
"""
I think Continue trace is one of Povray's best features, but I wouldn't mind to
disable it in the exporter for when we do border render, because the idea of
border render is to work faster, not render overnight and days. My request is
could the file simply be filled with black transparent pixels outside of the
rendered area, maybe when an optional keyword is added?
Blender developers seem to be fine with how image reading is happening now on
blender's side.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greetings,
Le 22/01/2011 12:19, Mr nous fit lire :
> Hi,
> We are trying to implement partial output (border render) into blender's
> exporter.
> What happens is that we got it working except opening the output image crashes
> blender. I suppose it's due to this fact mentioned in povray doc:
>
> """
> When rendering a subset of *rows* (+sr/+er) POV-Ray writes the full height into
> the image file header and only writes those lines into the image that are
> rendered. This can cause problems with image reading programs that are not
> checking the file while reading and just read over the end.
>
> If POV-Ray wrote the actual height of the partial image into the image header
> there would be no way to continue the trace in a later run.
> """
>
> I think Continue trace is one of Povray's best features, but I wouldn't mind to
> disable it in the exporter for when we do border render, because the idea of
> border render is to work faster, not render overnight and days. My request is
> could the file simply be filled with black transparent pixels outside of the
> rendered area, maybe when an optional keyword is added?
>
> Blender developers seem to be fine with how image reading is happening now on
> blender's side.
What are you trying to achieve ?
Which version are you using ?
testing with 3.7RC3 +sr & +er, with default to png file, seems fine: a
complete image is generated, with black for the unrendered parts.
If blender is calling povray, it surely know the +sr/+er/+sc/+ec, so can
read the relevant rectangle only.
Why did you mention Continue ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] free fr> wrote:
> Greetings,
>
> Le 22/01/2011 12:19, Mr nous fit lire :
> > Hi,
> > We are trying to implement partial output (border render) into blender's
> > exporter.
> > What happens is that we got it working except opening the output image crashes
> > blender. I suppose it's due to this fact mentioned in povray doc:
> >
> > """
> > When rendering a subset of *rows* (+sr/+er) POV-Ray writes the full height into
> > the image file header and only writes those lines into the image that are
> > rendered. This can cause problems with image reading programs that are not
> > checking the file while reading and just read over the end.
> >
> > If POV-Ray wrote the actual height of the partial image into the image header
> > there would be no way to continue the trace in a later run.
> > """
> >
> > I think Continue trace is one of Povray's best features, but I wouldn't mind to
> > disable it in the exporter for when we do border render, because the idea of
> > border render is to work faster, not render overnight and days. My request is
> > could the file simply be filled with black transparent pixels outside of the
> > rendered area, maybe when an optional keyword is added?
> >
> > Blender developers seem to be fine with how image reading is happening now on
> > blender's side.
>
> What are you trying to achieve ?
>
> Which version are you using ?
>
> testing with 3.7RC3 +sr & +er, with default to png file, seems fine: a
> complete image is generated, with black for the unrendered parts.
>
> If blender is calling povray, it surely know the +sr/+er/+sc/+ec, so can
> read the relevant rectangle only.
>
> Why did you mention Continue ?
I mentioned Continue Trace because of what's written in the doc,
What I'm trying to achieve is have the border_render property of blender set the
+sr +er +sc +ec ini file options, it does work: povray renders the proper part
of the image but, around when the render is finished, blender crashes.
Here is the modified script to replace in the svn exporter:
http://www.pasteall.org/18503/python
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
Le 22/01/2011 13:16, Mr nous fit lire :
>> > Which version are you using ?
And on what system ?
What is the image size (+H +W for povray) ?
>
> What I'm trying to achieve is have the border_render property of blender set the
> +sr +er +sc +ec ini file options, it does work: povray renders the proper part
> of the image but, around when the render is finished, blender crashes.
Huh ? If povray has exited, how can it crash blender ?
Does it also crash with a full picture ?
(I checked the exit status on linux 64 bits: povray returns 0, fine)
I'm just a bit concerned about the check of the
new_size = os.path.getsize(self._temp_file_out.name)
It might happen that the filesize has changed and that the file is not
yet finished... loading partial file is a bad idea.
(For RC2, if the full image is more than 1 048 576 pixels, disk I/O
would occurs, resulting in a slow creation of the final image at the end
of the render)
(For RC3, it's tunable, check the release note)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.01.2011 12:19, schrieb Mr:
> Hi,
> We are trying to implement partial output (border render) into blender's
> exporter.
> What happens is that we got it working except opening the output image crashes
> blender. I suppose it's due to this fact mentioned in povray doc:
>
> """
> When rendering a subset of *rows* (+sr/+er) POV-Ray writes the full height into
> the image file header and only writes those lines into the image that are
> rendered. This can cause problems with image reading programs that are not
> checking the file while reading and just read over the end.
>
> If POV-Ray wrote the actual height of the partial image into the image header
> there would be no way to continue the trace in a later run.
> """
As far as 3.7 is concerned, that section of the docs is actually
outdated: POV-Ray will /always/ write a complete image, with pixels
outside the rendered region filled with black. (This could be improved
for images with alpha channel, as I think it would make more sense to
set the "outside" pixels to all transparent there, but that's a
different topic.)
So maybe you should first investigate what blender actually /expects/. I
wouldn't be surprised if it would expect the rendered image to be
trimmed to the rendered region's size, rather than padded.
While it would definitely be possible to add a switch to POV-Ray to
change that behaviour, it doesn't make much sense to implement it right
/now/: There are currently plans for certain internal changes to how
POV-Ray buffers the output image during rendering, which will also
affected the very same portions of code that would have to be modified
for "your" feature; so chances are it won't be implemented before those
planned changes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/22/2011 09:05 AM, clipka wrote:
> As far as 3.7 is concerned, that section of the docs is actually
> outdated: POV-Ray will /always/ write a complete image, with pixels
> outside the rendered region filled with black.
sanity check: the next to the last sentence could be deleted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/22/2011 09:05 AM, Le_Forgeron wrote:
> It might happen that the filesize has changed and that the file is not
> yet finished... loading partial file is a bad idea.
>
> (For RC2, if the full image is more than 1 048 576 pixels, disk I/O
> would occurs, resulting in a slow creation of the final image at the end
> of the render)
> (For RC3, it's tunable, check the release note)
the I/O bottleneck fix correct? When running RC2 I /may/ have seen the
problem manifest itself on my system. As the scene was completing I had
jumped to the scene file text to make a change and save ... I had to
ctrl s a second time. Happened more than once, so now I think I know
what I was seeing. It might be a good idea for the blender folks to grab
RC3 and see if that gives them any joy!
also now that I've re-read:
http://wiki.povray.org/content/Documentation:Reference_Section_1#Partial_Output_Options
given the comments that have been made the last three paragraphs are
what needs to be changed ... the rows exception doesn't apply now
correct? and since that exception isn't valid anymore the last line can
go ...
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.01.2011 13:41, schrieb Jim Holsenback:
> On 01/22/2011 09:05 AM, Le_Forgeron wrote:
>> It might happen that the filesize has changed and that the file is not
>> yet finished... loading partial file is a bad idea.
>>
>> (For RC2, if the full image is more than 1 048 576 pixels, disk I/O
>> would occurs, resulting in a slow creation of the final image at the end
>> of the render)
>> (For RC3, it's tunable, check the release note)
>
> the I/O bottleneck fix correct? When running RC2 I /may/ have seen the
> problem manifest itself on my system. As the scene was completing I had
> jumped to the scene file text to make a change and save ... I had to
> ctrl s a second time. Happened more than once, so now I think I know
> what I was seeing. It might be a good idea for the blender folks to grab
> RC3 and see if that gives them any joy!
>
> also now that I've re-read:
>
http://wiki.povray.org/content/Documentation:Reference_Section_1#Partial_Output_Options
>
> given the comments that have been made the last three paragraphs are
> what needs to be changed ... the rows exception doesn't apply now
> correct? and since that exception isn't valid anymore the last line can
> go ...
Yup. To my understanding, the text
--------------------
When rendering a subset of *columns* (+sc/+ec) POV-Ray generates a full
width image and fills the not rendered columns with black pixels. This
should not be a problem for any image reading program no matter what
file format is used.
When rendering a subset of *rows* (+sr/+er) POV-Ray writes the full
height into the image file header and only writes those lines into the
image that are rendered. This can cause problems with image reading
programs that are not checking the file while reading and just read over
the end.
If POV-Ray wrote the actual height of the partial image into the image
header there would be no way to continue the trace in a later run.
--------------------
should be replaced with something like
--------------------
When rendering a subset of columns and/or rows, POV-Ray generates a full
width image and fills the not rendered columns with black pixels. This
should not be a problem for any image reading program no matter what
file format is used.
--------------------
Maybe add:
--------------------
(When rendering a subset of *rows* (+sr/+er) earlier versions of POV-Ray
wrote the full height into the image file header but only wrote image
data for those lines that were actually rendered, making such output
files incompatible with various image processing tools. This is no
longer the case as of POV-Ray 3.7.)
--------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 23.01.2011 13:41, schrieb Jim Holsenback:
> > On 01/22/2011 09:05 AM, Le_Forgeron wrote:
> >> It might happen that the filesize has changed and that the file is not
> >> yet finished... loading partial file is a bad idea.
> >>
> >> (For RC2, if the full image is more than 1 048 576 pixels, disk I/O
> >> would occurs, resulting in a slow creation of the final image at the end
> >> of the render)
> >> (For RC3, it's tunable, check the release note)
> >
> > the I/O bottleneck fix correct? When running RC2 I /may/ have seen the
> > problem manifest itself on my system. As the scene was completing I had
> > jumped to the scene file text to make a change and save ... I had to
> > ctrl s a second time. Happened more than once, so now I think I know
> > what I was seeing. It might be a good idea for the blender folks to grab
> > RC3 and see if that gives them any joy!
> >
> > also now that I've re-read:
> >
http://wiki.povray.org/content/Documentation:Reference_Section_1#Partial_Output_Options
> >
> > given the comments that have been made the last three paragraphs are
> > what needs to be changed ... the rows exception doesn't apply now
> > correct? and since that exception isn't valid anymore the last line can
> > go ...
>
> Yup. To my understanding, the text
>
>
> --------------------
> When rendering a subset of *columns* (+sc/+ec) POV-Ray generates a full
> width image and fills the not rendered columns with black pixels. This
> should not be a problem for any image reading program no matter what
> file format is used.
>
> When rendering a subset of *rows* (+sr/+er) POV-Ray writes the full
> height into the image file header and only writes those lines into the
> image that are rendered. This can cause problems with image reading
> programs that are not checking the file while reading and just read over
> the end.
>
> If POV-Ray wrote the actual height of the partial image into the image
> header there would be no way to continue the trace in a later run.
> --------------------
>
> should be replaced with something like
>
> --------------------
> When rendering a subset of columns and/or rows, POV-Ray generates a full
> width image and fills the not rendered columns with black pixels. This
> should not be a problem for any image reading program no matter what
> file format is used.
> --------------------
>
> Maybe add:
>
> --------------------
> (When rendering a subset of *rows* (+sr/+er) earlier versions of POV-Ray
> wrote the full height into the image file header but only wrote image
> data for those lines that were actually rendered, making such output
> files incompatible with various image processing tools. This is no
> longer the case as of POV-Ray 3.7.)
> --------------------
Thanks for all your answers and for the update to the documentation. I am using
latest(RC3 as of today) pov 3.7.
After discussing with Blender developers, it appears that when we use border
render, Blender expects a partial image not one with black, so the problem was
actually opposite to what I thought it was: POV-Ray's filling its image with
black provides a full size image whereas blender is expecting a tile. Blender
developers have chosen to provide a cropped partial image to allow more
flexibility for things like renderfarm setups or custom compositing pipelines,
if I understood correctly.
Now that the problem is clearer Blender developers will probably work around it,
but an option to chose tile/padded from POV could also be nice for the future if
it doesn't exist already.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Thanks for all your answers and for the update to the documentation. I am using
> latest(RC3 as of today) pov 3.7.
>
> After discussing with Blender developers, it appears that when we use border
> render, Blender expects a partial image not one with black, so the problem was
> actually opposite to what I thought it was: POV-Ray's filling its image with
> black provides a full size image whereas blender is expecting a tile. Blender
> developers have chosen to provide a cropped partial image to allow more
> flexibility for things like renderfarm setups or custom compositing pipelines,
> if I understood correctly.
> Now that the problem is clearer Blender developers will probably work around it,
> but an option to chose tile/padded from POV could also be nice for the future if
> it doesn't exist already.
>
>
If that option is ever added, I'd recomend making it an ini/command line
switch. I don't think that such a setting have it's place inside the
scene proper.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
