 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 30/09/2010 09:42, Chris Cason nous fit lire :
> On 30/09/2010 03:41, Le_Forgeron wrote:
>> I'm on something : a.resize(-1) in previous code (previous message) lead to:
>>
>> terminate called after throwing an instance of 'std::length_error'
>> what(): vector::_M_fill_insert
>> Abandon (core dumped)
>>
>>
>> Looks like vector does not like negative resize (due to promoting int(32
>> bits) to size_t after computation)
>
> Thanks for tracking this down - please feel free to raise a bug on it.
Your wish is my command, even if I prefer to see the bugs getting closed
than opened. (hint: #64 might get some progress)
I just took time to reduce the original size to still produce the bug
and yet keep it in memory (swap is crawling).
It won't be for the faint hearted: a 30500 x 30500 does still produces
the bug, but you'd better have 24 GB of true ram to test it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/30/2010 06:44 PM, Chris Cason wrote:
> On 1/10/2010 02:25, tth wrote:
>> Did you mean that POVray keep the full generated picture in memory
>> when rendering it ?
>
> Generally, yes.
This was not the case for 3.6.1 ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
tth <tth### [at] none invalid> wrote:
> On 09/30/2010 06:44 PM, Chris Cason wrote:
> > On 1/10/2010 02:25, tth wrote:
> >> Did you mean that POVray keep the full generated picture in memory
> >> when rendering it ?
> >
> > Generally, yes.
>
> This was not the case for 3.6.1 ?
I still use 3.6.1 and I tried it with 41000x41000 pixels. I used: +fn
display=off in the command line and it seems to be rendering OK, the image is
written right away on the hard disk.
I have quite an old computer with only 2 GB of RAM. I haven't had the patience
to wait until this test image was finished though, but I didn't get any error
messages or whatever, so I guess it works fine.
I don't know about version 3.7, is it not possible to switch of the display
anymore in that version?
Best wishes,
Simone
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/04/2010 04:07 PM, Simone wrote:
> I don't know about version 3.7, is it not possible to switch of the display
> anymore in that version?
the -d option works like it always has ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback <jho### [at] povrayorg> wrote:
> On 10/04/2010 04:07 PM, Simone wrote:
> > I don't know about version 3.7, is it not possible to switch of the display
> > anymore in that version?
>
> the -d option works like it always has ;-)
Uhm, I'm a little confused now.
In 3.6 I used to get an error with large images which said "failed to allocate
display bitmap" but with -d it worked fine.
But if the -d option works the same in 3.7 I wonder why there was the problem
with the large image fillibar wrote about in the first message?
Or does it mean that the display can be switched of with -d in 3.7 but still
needs all the memory for the display (unlike version 3.6)? But I thought the
main reason for switching off the display was to save memory (at least I can't
imagine another reason to use it.)
Best wishes,
Simone
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/04/2010 08:46 PM, Simone wrote:
> Jim Holsenback <jho### [at] povrayorg> wrote:
>> On 10/04/2010 04:07 PM, Simone wrote:
>>> I don't know about version 3.7, is it not possible to switch of the display
>>> anymore in that version?
>>
>> the -d option works like it always has ;-)
>
>
> Uhm, I'm a little confused now.
> In 3.6 I used to get an error with large images which said "failed to allocate
> display bitmap" but with -d it worked fine.
didn't you mention in an earlier post using display=off ... same as -d
> But if the -d option works the same in 3.7 I wonder why there was the problem
> with the large image fillibar wrote about in the first message?
>
look back several posts by Le Forgeron in this thread ...
> Or does it mean that the display can be switched of with -d in 3.7 but still
> needs all the memory for the display (unlike version 3.6)? But I thought the
> main reason for switching off the display was to save memory (at least I can't
> imagine another reason to use it.)
I don't think that's changed ... one of the devs that knows more about
the core could answer that for sure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 05/10/2010 01:46, Simone a écrit :
> Jim Holsenback <jho### [at] povrayorg> wrote:
>> On 10/04/2010 04:07 PM, Simone wrote:
>>> I don't know about version 3.7, is it not possible to switch of the display
>>> anymore in that version?
>>
>> the -d option works like it always has ;-)
>
>
> Uhm, I'm a little confused now.
> In 3.6 I used to get an error with large images which said "failed to allocate
> display bitmap" but with -d it worked fine.
>
> But if the -d option works the same in 3.7 I wonder why there was the problem
> with the large image fillibar wrote about in the first message?
>
> Or does it mean that the display can be switched of with -d in 3.7 but still
> needs all the memory for the display (unlike version 3.6)? But I thought the
> main reason for switching off the display was to save memory (at least I can't
> imagine another reason to use it.)
In 3.7, there is the memory for the display, and the memory for working
with the blocks (unless the transfer to disk for that is compiled in,
activated and working) that each thread renders.
In 3.6, the memory for working is limited to 2 pixel-lines (previous one
kept for antialiasing, current one in progress), and it does not support
multi-thread rendering.
Had you read the other messages in the subject, you would know already
that there is an issue with the computation of the memory size for
working blocks. It has been found (and I personally tested the fix with
a huge size, so I know that the identified reason is right), and a bug
report has been issued on the current beta. You will have to wait for
the next beta before trying again.
So yes, disabling display might still save some memory, but so far 3.7
is not as compact as 3.6 when used with huge size.
If you want be afraid, the current allocation (without special option is
5 floats (of 32 bits) per pixel, before the start of the render. Do the
maths for yourself, and keep in mind that when writing the final file,
you need yet another chunk because most libraries use a memory approach
too (but it is usually only 3 or 4 bytes per pixel), even if they
compress later the output before reaching the disk.
I got access to a 24 GBytes system, it is about just enough for 30500 x
30500 (to png). (it starts rendering at 18 GB...)
Might I ask on what display are you using a 41000 x 41000 picture ?
It took more than a 4m x 3m advertisement poster with the fine details
of handheld publication (10 pixels/mm).
--
Real software engineers work from 9 to 5, because that is<br/>
the way the job is described in the formal spec. Working<br/>
late would feel like using an undocumented external procedure.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Might I ask on what display are you using a 41000 x 41000 picture ?
> It took more than a 4m x 3m advertisement poster with the fine details
> of handheld publication (10 pixels/mm).
The image is a very small galaxy of the following dimensions,
~41,000x41,000x10,000ly. Our current star grouping has ~12M coordinates (stars
only) which are being placed as single unit (1ly) white spheres. I am mainly
trying to generate the image for a top view. While I am normally rendering it at
a max of 12800x10240 (which takes ~10hrs to finish rendering) the even larger
image was desired so we could break down the exact locations better and allow
extreme zooming to a specific coordinate (or at least the 2D representation of
it).
So basically it was an idea to get a ~1ly:1pixel representation of the galaxy in
the image.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 05/10/2010 14:43, fillibar a écrit :
>> Might I ask on what display are you using a 41000 x 41000 picture ?
>> It took more than a 4m x 3m advertisement poster with the fine details
>> of handheld publication (10 pixels/mm).
>
> The image is a very small galaxy of the following dimensions,
> ~41,000x41,000x10,000ly. Our current star grouping has ~12M coordinates (stars
> only) which are being placed as single unit (1ly) white spheres. I am mainly
> trying to generate the image for a top view. While I am normally rendering it at
> a max of 12800x10240 (which takes ~10hrs to finish rendering) the even larger
> image was desired so we could break down the exact locations better and allow
> extreme zooming to a specific coordinate (or at least the 2D representation of
> it).
>
> So basically it was an idea to get a ~1ly:1pixel representation of the galaxy in
> the image.
>
>
My inquiring mind is satisfied. I hope you are using +Q0 and wonder
about any AA setting or removal (sub-sampling might just be the right
thing, without heuristic). With an orthographic camera I suppose.
Also, you might replace spheres with viewing axis-aligned boxes (with
+Q0, not an issue of shading and as long as the picture resolution is
less than the coordinates, a spherical or boxed pixels is the same), it
might save some square root computations. I guess the parsing of the 12M
is not funny.
Notice that the final density would be 1 white pixel per 140 pixels.
(at 41000x41000), if there is no black borders.
--
Real software engineers work from 9 to 5, because that is<br/>
the way the job is described in the formal spec. Working<br/>
late would feel like using an undocumented external procedure.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <lef### [at] freefr> wrote:
> and keep in mind that when writing the final file,
> you need yet another chunk because most libraries use a memory approach
> too (but it is usually only 3 or 4 bytes per pixel), even if they
> compress later the output before reaching the disk.
Most image format read/write libraries support reading/writing the image
in small portions at a time, for this precise reason. For example, pnglib
only requires a few kilobytes of RAM to write even huge PNGs, and you can
feed it pixel data in small groups.
So converting the image to 8-bit-per-component RGBA and writing to PNG
shouldn't be the problem (because the conversion can be done a few pixels
at a time).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
