 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nekar Xenos" <nek### [at] gmail com> wrote:
>
> Does it also happen with beta 39?
>
> -Nekar Xenos-
I'm currently rendering at a lower resolution, still may take some time
(radiosity, you know...). When it finished I'll install 39 and you'll be the
first to know! :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nekar Xenos" <nek### [at] gmailcom> wrote:
> On Mon, 08 Nov 2010 14:47:28 +0200, stevenvh <nomail@nomail> wrote:
>
> Does it also happen with beta 39?
>
Yes, it also happens with beta 39. Odd thing: the first iteration is very slow
as expected (we're talking about radiosity on a large number of objects), but
when the messages start to pop up, the following iterations are passing very
quickly, until the rendering stops with the "render failed" message while it's
rendering at pixel level. My hunch is that radiosity is ignored; successive
pixels are just generated too quickly.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 08.11.2010 18:26, schrieb stevenvh:
> Yes, it also happens with beta 39. Odd thing: the first iteration is very slow
> as expected (we're talking about radiosity on a large number of objects), but
> when the messages start to pop up, the following iterations are passing very
> quickly, until the rendering stops with the "render failed" message while it's
> rendering at pixel level. My hunch is that radiosity is ignored; successive
> pixels are just generated too quickly.
That may also be simply due to a low per-pixel radiosity sample density,
i.e. POV-Ray needs to compute less radiosity samples per pixel. (When
you increase the resolution of an image, POV-Ray does not automatically
increase the number of radiosity samples.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 08.11.2010 18:26, schrieb stevenvh:
>
> > Yes, it also happens with beta 39. Odd thing: the first iteration is very slow
> > as expected (we're talking about radiosity on a large number of objects), but
> > when the messages start to pop up, the following iterations are passing very
> > quickly, until the rendering stops with the "render failed" message while it's
> > rendering at pixel level. My hunch is that radiosity is ignored; successive
> > pixels are just generated too quickly.
>
> That may also be simply due to a low per-pixel radiosity sample density,
> i.e. POV-Ray needs to compute less radiosity samples per pixel. (When
> you increase the resolution of an image, POV-Ray does not automatically
> increase the number of radiosity samples.)
I am seeing this with beta 40 as well... and the image is not huge.
Copied biscuit.pov into my $HOME and...
povray +ibiscuit.pov +v +w1920 +h1200 +a0.3
Says:
==== [Rendering...] ========================================================
Intermediate image storage backing file seek failed.
Rendered 1024 of 2304000 pixels (0%)ile seek failed.
Fatal error in renderer: Frontend halted render.
Intermediate image storage backing file seek failed.
Intermediate image storage backing file seek failed.
Render failed
When I do it at a smaller size:
povray +ibiscuit.pov +v +w320 +h240 +a0.3
It works (in 1.345 seconds of trace time, btw -- nice).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A little more information.
When SetLine fails, it fails on the fseek64 because the fseek64 is returning a
non-zero number.
In this case it is returning the value of pos ... for example on an image that
has an m_Width of 1920 where y = 1, pos = 38400, fseek64 is returning 38400.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jon Boede" <jbo### [at] victhompsoncom> wrote:
> A little more information.
>
> When SetLine fails, it fails on the fseek64 because the fseek64 is returning a
> non-zero number.
>
> In this case it is returning the value of pos ... for example on an image that
> has an m_Width of 1920 where y = 1, pos = 38400, fseek64 is returning 38400.
This is because the UNIX version of povray fakes up the call to fseek64 as
lseek64(fileno(m_File) ... ) and since they return different values, this causes
confusion.
Have filed this under bugs.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here's a workaround until we get a fixed tarball (and which doesn't require
a full re-compile).
Open source/base/image.cpp and add
#define _FILE_OFFSET_BITS 64
to the start (before any system headers).
Then, replace any instance of fseek64() with fseeko().
That should do it.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've patched the tarball on the site, but haven't had a chance to build it
(I did test locally however). If someone could please grab it again and let
me know if it is OK I'll add a note to the source download page mentioning
the fix.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/06/2010 05:52 PM, Chris Cason wrote:
> Here's a workaround until we get a fixed tarball (and which doesn't require
> a full re-compile).
>
> Open source/base/image.cpp and add
>
> #define _FILE_OFFSET_BITS 64
sorry 'bout that chief ... guess it's a good thing i'm ok with a bit of
egg on my face ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/12/2010 09:42, Jim Holsenback wrote:
> sorry 'bout that chief ... guess it's a good thing i'm ok with a bit of
> egg on my face ;-)
Not your fault:). The #define by itself doesn't bring in fseek64, that's
why it didn't work originally. Hence the change to fseeko() in this case.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
