 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
pirateprincess wrote:
> I have been working with .POV scenes generated from PyMOL (PDB crystal
> structure files). I am trying to tesselate a specific crystal structure
> image across a plane and have utilized 15-20 copies of a simple DNA double
> helix. The .POV file is roughly 30 megabytes. I am working on a quad-core
> G5 (Mac OS X 10.4.9, Pov-Ray 3.6.1 for Mac) with 4GB RAM and am receiving an
> error that reads "Parse Error: Out of memory. Cannot allocate 116 bytes for
> finish. File my_scene.pov line 665798"
>
> Are there simple ways to fix this problem? Is more information needed to
> help diagnose the problem / suggest a solution?
It would probably help to see an *excerpt* of your generated code
with the bulk of the data removed so we see the object structure.
AFAIK, if it is a mesh then additional copies should not take
extra memory, but if its other objects that may be different.
Also, you should watch the memory consumption of the process while
parsing to see how much memory is actually used (don't know how this
is done on Mac, though). Also, I'm not sure if all of the 4GB will
be accessible to a single process (again, don't know about Mac).
Finally, I reckon the level of detail in your object is larger
than would actually be required for your purpose, maybe there are
some export settings in your program to reduce the output size?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"pirateprincess" <pir### [at] charter net> wrote:
> "nemesis" <nam### [at] gmailcom> wrote:
> > following Thomas suggestion, I'd also urge you to apply just one finish to
> > the whole union instead at each copy. I'm also curious as to the storage
> > format to the DNA structure: it looks like it's a mesh, right?
>
>
> Thanks for this suggestion. I am very very new to this program, I am a
> chemist who is trying to make a graphic for a Journal cover. The DNA
> structure comes from a crystal structure visualizing program that I am
> familiar with using. Once I get the view of the helix as I want it to
> appear, I export to POVray using a script. When it comes into POVray, the
> helix consists of about 20,000 lines of code, mostly spheres and cylinders,
> that I guess is what the program translates the image from the crystal
> structure program as. I then just put a declare statement around all 20,000
> lines of code and work with the declared identity. I will try your
> suggestion of moving the finish to the union instead of in the original
> description. I'm sorry, I don't know what you mean about it looks like it's
> a mesh.
>
> Another thing I should add to the above, I want to have a protein crystal
> structure in the image above, and its description as it comes from the
> crystal structure program is over 50,000 lines of code! I need at least 10
> copies of this to appear as well, but am despairing of it being possible!
>
> Thanks for the help, I will report back on the attempts to move the finish.
I don't know how useful it would be to you, but Noam Lewis made a free DNA
helix macro for POV ray: http://objects.povworld.org/cat/Misc/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
this is an interesting experiment and I thought it'd be useful to share with
you.
I made this simple scene to test:
background { rgb .6 }
#local dna_base = union {
sphere { 0, 1 pigment { rgb z } translate y*2 }
cylinder { -y,y .2 pigment { rgb x } }
sphere { 0, 1 pigment { rgb z } translate -y*2 }
}
#declare dna =
union {
#local i = 0;
#while (i < 100000)
object { dna_base rotate x*45*i
translate -2*y*sin(i+1)/2 +1.2*x*(i+1)
}
#declare i = i + 1;
#end
}
object { dna
translate z*140
}
light_source { 10*(4-8*z) 1.2 }
and the memory consumption quickly got over 200MB, at which point I halted
the process and started over a slightly modified scene:
background { rgb .6 }
#local dna_base = union {
sphere { 0, 1 pigment { rgb z } translate y*2 }
cylinder { -y,y .2 pigment { rgb x } }
sphere { 0, 1 pigment { rgb z } translate -y*2 }
}
#declare dna =
union {
#local i = 0;
#while (i < 1000 )//100000)
object { dna_base rotate x*45*i
translate -2*y*sin(i+1)/2 +1.2*x*(i+1)
}
#declare i = i + 1;
#end
}
union {
#local i = 0;
#while (i < 100 )//100000)
object { dna translate -2*y*(i+1) }
#declare i = i + 1;
#end
translate z*140
}
light_source { 10*(4-8*z) 1.2 }
well, forget it: CSG really turns povray into a memory hog no matter what
you do. It has gone over 200MB as well and I halted again. It just took a
lot more time to get there. Important lesson here: better few unions with
lots of objects than lots of unions with fewer (but huge!) objects...
So I guess it's your choice: get a true solid surface for insane amounts of
memory or a resolution-limited but much more economic polygonal mesh...
thank god the DNA isn't an isosurface! :P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
pirateprincess nous apporta ses lumieres en ce 17 / 05 / 2007 13:53:
> "nemesis" <nam### [at] gmailcom> wrote:
>> following Thomas suggestion, I'd also urge you to apply just one finish to
>> the whole union instead at each copy. I'm also curious as to the storage
>> format to the DNA structure: it looks like it's a mesh, right?
>
>
> Thanks for this suggestion. I am very very new to this program, I am a
> chemist who is trying to make a graphic for a Journal cover. The DNA
> structure comes from a crystal structure visualizing program that I am
> familiar with using. Once I get the view of the helix as I want it to
> appear, I export to POVray using a script. When it comes into POVray, the
> helix consists of about 20,000 lines of code, mostly spheres and cylinders,
> that I guess is what the program translates the image from the crystal
> structure program as. I then just put a declare statement around all 20,000
> lines of code and work with the declared identity. I will try your
> suggestion of moving the finish to the union instead of in the original
> description. I'm sorry, I don't know what you mean about it looks like it's
> a mesh.
>
> Another thing I should add to the above, I want to have a protein crystal
> structure in the image above, and its description as it comes from the
> crystal structure program is over 50,000 lines of code! I need at least 10
> copies of this to appear as well, but am despairing of it being possible!
>
> Thanks for the help, I will report back on the attempts to move the finish.
>
>
>
One thing you can do, is to use reflections to show the same original object
multiple times.
--
Alain
-------------------------------------------------
WARNING: The consumption of alcohol may make you think you are whispering when
you are not.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"pirateprincess" <pir### [at] charternet> wrote in message
news:web.464bdea734f9c3f4d5b864c00@news.povray.org...
> Are there simple ways to fix this problem? Is more information needed to
> help diagnose the problem / suggest a solution?
If you were on a PC, I'd say to change your performance settings in
control panel to 2024Mb's and 4048Mb's respectively. Is there such a thing
with a Mac?
Sorry I couldn't help any better than this.
~Steve~
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
pirateprincess wrote:
> I have been working with .POV scenes generated from PyMOL (PDB crystal
> structure files). I am trying to tesselate a specific crystal structure
> image across a plane and have utilized 15-20 copies of a simple DNA double
> helix. The .POV file is roughly 30 megabytes. I am working on a quad-core
> G5 (Mac OS X 10.4.9, Pov-Ray 3.6.1 for Mac) with 4GB RAM and am receiving an
> error that reads "Parse Error: Out of memory. Cannot allocate 116 bytes for
> finish. File my_scene.pov line 665798"
>
> Are there simple ways to fix this problem? Is more information needed to
> help diagnose the problem / suggest a solution?
The 4 GB of RAM won't help a GUI application such as POV-Ray as those
applications cannot use more then 3 GB of memory each, regardless of how
much memory your system has.
To get over this limit, you need a 64 bit command line application, which
you would have to compile yourself based on the Unix source code of POV-Ray.
Apple includes all development tools you need in addition to the POV-Ray
source code (but the development tools are not installed by default).
However, it isn't trivial if you have never done this before.
Thorsten, POV-Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christian Froeschlin" <chr### [at] chrfrde> schreef in bericht
news:464ca294$1@news.povray.org...
>
> It would probably help to see an *excerpt* of your generated code
> with the bulk of the data removed so we see the object structure.
> AFAIK, if it is a mesh then additional copies should not take
> extra memory, but if its other objects that may be different.
>
Yes, I second that! So we can see if the structure is built up out of
spheres and cylinders, or if it is built up out of mesh2 objects.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
From: Christian Froeschlin
Subject: Re: Rendering memory limitations
Date: 18 May 2007 15:04:42
Message: <464df8ca@news.povray.org>
|
|
|
| |
| |
|
|
nemesis wrote:
> well, forget it: CSG really turns povray into a memory hog no matter what
> you do. It has gone over 200MB as well and I halted again. It just took a
> lot more time to get there. Important lesson here: better few unions with
> lots of objects than lots of unions with fewer (but huge!) objects...
Well, the real killers seem to be the individual pigments on
your 300.000 objects. The stats on my system for your scene 1:
Largest Alloc: 2400016 bytes
Peak memory used: 832856013 bytes
Applying the same pigment for all objects in the outermost union:
Largest Alloc: 2400016 bytes
Peak memory used: 374455173 bytes
Actually, I usually prefer to use a blob object for rendering a
lot of spheres if I can get away with it, because it seems to render
a lot faster, especially with intersections such as water bubbles.
Blobbed version also helps memory (but yields domed cylinder caps):
Largest Alloc: 60000016 bytes
Peak memory used: 152359044 bytes
I intentionally ignored the parse time: For the first version
most of the time was spent swapping, for the other versions the
times are similar and probably dominated by the SDL text
parser and not by efficency of data structures.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"pirateprincess" <pir### [at] charternet> wrote:
> I only have the code for the DNA written out once, declared as an object as
> you have described below. Then to get the full picture, I have unions of
> various numbers of the helix declared as seperate objects. This has allowed
> me to work with only one or two of the helices at a time in order to get
> them the way I want them. But now that I am trying to view my final scene
> with all the copies, it is running out of memory.
>
Depending on the rest of the scene (shadows and reflections would make the
following technique more difficult) you could render the individual helices
using a transparent background (+UA command line option) and then combine
the images using a photo editor.
Mike S.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Sobers nous apporta ses lumieres en ce 2007/06/01 01:11:
> "pirateprincess" <pir### [at] charternet> wrote:
>
>> I only have the code for the DNA written out once, declared as an object as
>> you have described below. Then to get the full picture, I have unions of
>> various numbers of the helix declared as seperate objects. This has allowed
>> me to work with only one or two of the helices at a time in order to get
>> them the way I want them. But now that I am trying to view my final scene
>> with all the copies, it is running out of memory.
>>
>
> Depending on the rest of the scene (shadows and reflections would make the
> following technique more difficult) you could render the individual helices
> using a transparent background (+UA command line option) and then combine
> the images using a photo editor.
>
> Mike S.
>
>
OR, you can do a final render using those as image_map on very thin boxes or 2
triangles mesh or planes.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
