 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 05/10/2010 01:46, Simone a écrit :
> Jim Holsenback <jho### [at] povray org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
>
>
In that case, why not create a mosaic of smaller images that you can
assemble and display as needed.
That way, you can have a collection of, say, 1000x1000 pixels tiles,
with possibly a small overlap. You only have at most 4 images loaded in
memory at any time.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 05/10/2010 19:08, Warp nous fit lire :
> 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).
>
You are correct.
But testing an empty scene (well, 1 camera, 1 light source) with a 20500
x 20500 size gives the following observations:
(-A -D)
memory used on system jumps to 9.6G at the render start.
It raises as it progress to 16G.
When file-write start, (1 & 1/4 active threads), memory stay at 16G.
Then drops to 9.1G and only 1 thread stays with 100% while the write
finishes... a delay might be observed once the write ends and before the
program exits (sometime).
The 25% thread might be some garbage collector... but it looks like
there is a memory leak while rendering (I would have expected all
allocation do have been done once all rendering threads have been
created (well, short of temporary objects like intersections stacks...)
6.4G is not a small increase.
Note to self: best WT values (for a huge & empty scene) of cpu
efficiency seems to be number of HTcores -1 (so the scheduler push them
full frequency). As soon as WT number reaches number of cores, they are
slowed down to approx 60% on the system chart. (thread collisions is
probable)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> >
> In that case, why not create a mosaic of smaller images that you can
> assemble and display as needed.
> That way, you can have a collection of, say, 1000x1000 pixels tiles,
> with possibly a small overlap. You only have at most 4 images loaded in
> memory at any time.
>
>
> Alain
I am presently looking at that, using 8100x8100 tiles BUT I am worried about how
that will affect their orientation since I will have to reposition the camera in
every case to maximize usage of the 8100 but to somehow also have it match up
how it would look as if I was viewing the larger image.
To a prior recommendation about using boxes I think I can give that a shot to
see if it helps.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>
>> In that case, why not create a mosaic of smaller images that you can
>> assemble and display as needed.
>> That way, you can have a collection of, say, 1000x1000 pixels tiles,
>> with possibly a small overlap. You only have at most 4 images loaded in
>> memory at any time.
>>
>>
>> Alain
>
> I am presently looking at that, using 8100x8100 tiles BUT I am worried about how
> that will affect their orientation since I will have to reposition the camera in
> every case to maximize usage of the 8100 but to somehow also have it match up
> how it would look as if I was viewing the larger image.
>
> To a prior recommendation about using boxes I think I can give that a shot to
> see if it helps.
>
>
If you are using an orthographic camera, you only need to move the
camera up/down right/left .
If you use a normal perspective camera, then you can shear the camera
using a matrix transform. In that case, you don't move the camera.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] freefr> wrote:
> You are correct.
> But testing an empty scene (well, 1 camera, 1 light source) with a 20500
> x 20500 size gives the following observations:
> (-A -D)
> memory used on system jumps to 9.6G at the render start.
With which version of POV-Ray? Currently 3.7beta does indeed allocate
RAM for the entire image. 3.6 shouldn't (when display is off).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 10/10/2010 09:20, Warp nous fit lire :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> You are correct.
>> But testing an empty scene (well, 1 camera, 1 light source) with a 20500
>> x 20500 size gives the following observations:
>> (-A -D)
>
>> memory used on system jumps to 9.6G at the render start.
>
> With which version of POV-Ray? Currently 3.7beta does indeed allocate
> RAM for the entire image. 3.6 shouldn't (when display is off).
>
I'm using the 3.7Beta of course.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
