I am trying to render a protein (definition file exported from vmd).
Admittedly this thing is huge (800Mb input file with 3.3 million
triangles). I am trying to do this on a 4x200 PPRO debian/linux machine
with 1.5Gb physical memory and about 4GB of swap space.

Povray 3.5 successfully reads the whole input file in about an hour and then
gives up with:

  Creating bounding slabs.
  Scene contains 3285051 frame level objects; 0 infinite.
  Slab Building Error: Out of memory.  Cannot allocate 26280408 bytes for
  bounding boxes.

Interestingly, at the time it povray complains, top reports that it is only
using about 2.6Gb of memory, i.e. there should still be about 3Gb left ...
any hints what I am doing wrong or what I could tweak to get there?

  Rudolf

Post a reply to this message

In article <web.41c5f5f337c0aed94d80a0910@news.povray.org> , "frumpel" 
<nomail@nomail> wrote:

> Interestingly, at the time it povray complains, top reports that it is only
> using about 2.6Gb of memory, i.e. there should still be about 3Gb left ...
> any hints what I am doing wrong or what I could tweak to get there?

The maximum address space of an application is the limit, not the limit of
swap space.  On a 32 bit system the maximum address space is 2**32 (4 GB).
This is a hardware address limit as a 32 bit pointer simply cannot address
more than 4 GB of memory.   Still, the application memory available is
further limited (for not easy to explain reasons) to something between 2 GB
to 3.5 GB depending on the operating system on 32 bit systems.

    Thorsten

PS: Note that you are using an outdated version of POV-Ray.  Also, note that
if you are using the package supplied by Debian, you are running an
unsupported version of POV-Ray with several extremely buggy patches added by
Debian the maintainer.

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

frumpel <nomail@nomail> wrote:
>   Scene contains 3285051 frame level objects; 0 infinite.

  Put your triangles inside a mesh, not inside a union (or all by
themselves).

  As a bonus, if you #declare this mesh, you will be able to make copies
of it at no extra cost (memorywise).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

web.41c5f5f337c0aed94d80a0910@news.povray.org...

> Interestingly, at the time it povray complains, top reports that it is 
> only
> using about 2.6Gb of memory, i.e. there should still be about 3Gb left ...
> any hints what I am doing wrong or what I could tweak to get there?

Someone (see message in this group by Uplah on 24/10) reported a similar 
problem with a large protein exported by VMD, so it could be that VMD 
doesn't export very efficient POV-Ray code memory-wise. I haven't seen 
POV-Ray code produced by VMD but I wouldn't be surprised to see thousands of 
texture statements when a single one would be necessary, or mesh coordinates 
duplicated when instanciation could be used. Perhaps VMD users could report 
this issue to the developers to see how it can be fixed. Meanwhile, the only 
solution could be to write a utility that would process the VMD's POV-Ray 
code into something more memory-friendly.

G.


-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote:
> The maximum address space of an application is the limit, not the limit of
> swap space.  On a 32 bit system the maximum address space is 2**32 (4 GB).

Duh! Sorry, I should have known that but it's been since my ATARI days that
I have run into this last (short pointers and 32k addressable blocks) so I
just didn't think about this ;)

Thanks,

  Rudolf

Post a reply to this message