 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
I'm having a problem trying to render large autamatically generated pov
files. These are representations of a surface built up from thousands
of individual triangles. A sample entry would be....
colored_smooth_triangle (
<-10.304373,-12.849998,-6.025000>, <-0.526939,0.609252,-0.592577>, rgbt
<0.470588,0.470588,1.000000,0.000000>,
<-9.650002,-12.315180,-6.025000>, <-0.583489,0.698051,-0.415048>, rgbt
<0.760784,0.760784,1.000000,0.000000>,
<-9.858542,-12.849998,-6.775000>, <-0.732888,0.622233,-0.275139>, rgbt
<0.760784,0.760784,1.000000,0.000000>
)
Unfortunately, POV doesn't seem to like this size of file (about 6Mb
upwards!), and will crash whilst parsing the file with an error saying
it is unable to allocate sufficient memory when creating bounding slabs.
Is there anything I can do to increase my chances of getting these to
parse without errors?? I already have 128Mb RAM and that won't parse a
6Mb .pov file - some of my files are >100Mb!!, so I suspect that just
adding more RAM won't completely cure it. I have plenty of HDD space so
I can give it all the virtual memory it could need, if that is any use.
Is this just the sort of file that POV hates and I should find another
way to get these pictures??
Any and all advice is welcome
Many thanks
Simon
--
Simon Andrews
BBSRC Bioscience IT Services
e.mail: sim### [at] bbsrc acuk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Simon Andrews wrote:
>
> Hi,
>
> I'm having a problem trying to render large autamatically generated pov
> files. These are representations of a surface built up from thousands
> of individual triangles. A sample entry would be....
>
> colored_smooth_triangle (
> <-10.304373,-12.849998,-6.025000>, <-0.526939,0.609252,-0.592577>, rgbt
> <0.470588,0.470588,1.000000,0.000000>,
> <-9.650002,-12.315180,-6.025000>, <-0.583489,0.698051,-0.415048>, rgbt
> <0.760784,0.760784,1.000000,0.000000>,
> <-9.858542,-12.849998,-6.775000>, <-0.732888,0.622233,-0.275139>, rgbt
> <0.760784,0.760784,1.000000,0.000000>
> )
>
> Unfortunately, POV doesn't seem to like this size of file (about 6Mb
> upwards!), and will crash whilst parsing the file with an error saying
> it is unable to allocate sufficient memory when creating bounding slabs.
>
> Is there anything I can do to increase my chances of getting these to
> parse without errors?? I already have 128Mb RAM and that won't parse a
> 6Mb .pov file - some of my files are >100Mb!!, so I suspect that just
> adding more RAM won't completely cure it. I have plenty of HDD space so
> I can give it all the virtual memory it could need, if that is any use.
> Is this just the sort of file that POV hates and I should find another
> way to get these pictures??
>
> Any and all advice is welcome
> Many thanks
>
> Simon
I can only guess by the "colored_smooth_triangle" that you are using
the include file by Chris Colefax. If that is the case it is not the
size of the file that is causing the problem. It is the proceedural
macros that calculate the colors and position of the triangles that
is consuming all of your memory. You should definately allocate swap
file space if you are going to be running files of this type. If you
are running windows just let it handle the virtual memory requirements
for your system and you should have no more problems.
Even if I am wrong about you using the tricolor.inc file by Chris
you can imagine how many memory pointers the program must allocate
to store the color information for each corner of each triangle in
a large triangle bearing file. Installing more system ram will make
the program run more efficiently and will require less parsing and
rendering times but there is no reason for you not to at least try
using a swap file first to see if you can eliminate your current
problem.
--
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !
Ken Tyler - 1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38576D07.7DFB478E@bbsrc.ac.uk>, sim### [at] bbsrcacuk
says...
> Hi,
>
> Is there anything I can do to increase my chances of getting these to
> parse without errors?? I already have 128Mb RAM and that won't parse a
> 6Mb .pov file - some of my files are >100Mb!!, so I suspect that just
> adding more RAM won't completely cure it. I have plenty of HDD space so
> I can give it all the virtual memory it could need, if that is any use.
> Is this just the sort of file that POV hates and I should find another
> way to get these pictures??
Hey!
What platform are you using to do so? I had troubles rendering huge .pov
files (meshes, yes...) using just DOS, on Intel. U can help yourself a
bit using some 3rd party program as VMEM, that simulates memory out of
disk, but then it gets too slow. Under Win32 (NT 4 actually) i had no
problems dealing with 10mb .pov files. The same goes for Solaris, the
largest one was some animation, .pov was like 12 megs, and Sun SPARC20
took like 2 hrs to parse and render a frame....
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
With very big files like this I've found that restarting windows helps.
Mick
Mario Splivalo <msp### [at] jagorsrcehr> wrote in message
news:MPG.12c19024acb6a6c2989684@news.povray.org...
> In article <38576D07.7DFB478E@bbsrc.ac.uk>, sim### [at] bbsrcacuk
> says...
> > Hi,
> >
> > Is there anything I can do to increase my chances of getting these to
> > parse without errors?? I already have 128Mb RAM and that won't parse a
> > 6Mb .pov file - some of my files are >100Mb!!, so I suspect that just
> > adding more RAM won't completely cure it. I have plenty of HDD space so
> > I can give it all the virtual memory it could need, if that is any use.
> > Is this just the sort of file that POV hates and I should find another
> > way to get these pictures??
>
> Hey!
>
> What platform are you using to do so? I had troubles rendering huge .pov
> files (meshes, yes...) using just DOS, on Intel. U can help yourself a
> bit using some 3rd party program as VMEM, that simulates memory out of
> disk, but then it gets too slow. Under Win32 (NT 4 actually) i had no
> problems dealing with 10mb .pov files. The same goes for Solaris, the
> largest one was some animation, .pov was like 12 megs, and Sun SPARC20
> took like 2 hrs to parse and render a frame....
>
> Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
DOS POV has its own virtual memory manager (IIRC, the Causeway DOS extender),
which to my knowledge should have no (practical) limitation on swap file size.
So you should not run out of memory that easily (and a 3rd party VMM shouldn't
be of much help). I have rendered fairly memory-intensive scenes in DOS.
Some VMMs do have a memory limitation. But unless you use a custom compile, I
don't see why you have his problem.
Margus
Mario Splivalo wrote:
>
> What platform are you using to do so? I had troubles rendering huge .pov
> files (meshes, yes...) using just DOS, on Intel. U can help yourself a
> bit using some 3rd party program as VMEM, that simulates memory out of
> disk, but then it gets too slow.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote...
>
> I can only guess by the "colored_smooth_triangle" that you are using
> the include file by Chris Colefax. If that is the case it is not the
> size of the file that is causing the problem. It is the proceedural
> macros that calculate the colors and position of the triangles that
> is consuming all of your memory.
The macros and also the textures could be taking up memory. Chris's macros
most likely generate one texture for each triangle, possible with layers
(haven't looked at the code myself). That would consume a lot of memory.
You may wish to test out MegaPov, which includes the smooth_color_triangle
patch which allows such triangles to be rendered directly within a triangle
mesh object, which could save lots of memory. If that does the trick, send
a nice thank-you to Ansgar Philippsen, who wrote the patch (email in the
MegaPov docs). :-)
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
>
> Ken <tyl### [at] pacbellnet> wrote...
> >
> > I can only guess by the "colored_smooth_triangle" that you are using
> > the include file by Chris Colefax. If that is the case it is not the
> > size of the file that is causing the problem. It is the proceedural
> > macros that calculate the colors and position of the triangles that
> > is consuming all of your memory.
>
> The macros and also the textures could be taking up memory. Chris's macros
> most likely generate one texture for each triangle, possible with layers
> (haven't looked at the code myself). That would consume a lot of memory.
>
> You may wish to test out MegaPov, which includes the smooth_color_triangle
> patch which allows such triangles to be rendered directly within a triangle
> mesh object, which could save lots of memory. If that does the trick, send
> a nice thank-you to Ansgar Philippsen, who wrote the patch (email in the
> MegaPov docs). :-)
>
> -Nathan
Even assuming that he is using the internal funtion would it not be safe to
assume that if you specify a seperate color for each corner of a triangle that
you would still comsume considerably larger amounts of memory than if you
were to texture the mesh seperately ? Seems to me like this feature would
require quite a few memory pointers to the color locations.
--
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !
Ken Tyler - 1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote ...
>
> Even assuming that he is using the internal funtion would it not be safe
to
> assume that if you specify a seperate color for each corner of a triangle
that
> you would still comsume considerably larger amounts of memory than if you
> were to texture the mesh seperately ? Seems to me like this feature would
> require quite a few memory pointers to the color locations.
The smooth_color_triangle patch uses a single color value for each point.
Let's see here, I think there's 4*5=20 bytes per color, 8*3=24 bytes per
vertex, 8*3=24 bytes per normal, 4 bytes per texture pointer, and 4 bytes
per integer index. So, if you have unique 1,000 vertices making up maybe
800 triangles, you would have:
colors + vertices + normals +
indices for all three + pointers for textures
20,000+24,000+24,000+3,200*3+3,200=80,800 bytes
Without colors, you'd get
24,000+24,000+3,200*2+3,200=57,600 bytes
So, the colors make up less than a third of the data. I have oversimplified
this, but the general idea is correct.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] koppcom> wrote:
: The smooth_color_triangle patch uses a single color value for each point.
Isn't it possible to specify a complete pigment (or even texture) for
each point? If not, shouldn't it be modified to support them?
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello again,
Thanks to all who have replied and tried to help me sort this one out.
I'm still having no joy getting these things to render even having
played around with various memory settings.
The files themselves are generated by a couple of molecular modelling
packages. The .inc files they generate are simple object descriptions,
containing 50000+ (in some cases a lot more!) smooth triangle
descriptions with no subroutines to other .inc files. It would appear
that it's merely the number of objects which is causing problems (though
surely some of the complex scenes I have seen published must contain a
comparable number of objects??).
A couple of other things which may (or may not) be important...
I am running under Windows NT 4, I have a 250Mb swap file available in
addition to 128Mb memory. Increasing the swap to 500Mb didn't help.
Restarting windows didn't seem to improve things either.
When the file parses I get a lot (100+) of errors from the renderer. I
get these even from files which eventually render fine - I assume they
are a bug in the .inc file generation algorithm. They are usually of
the form
Degenerate triangle - please remove
or CSG union unnecesarily bounded
The sheer number of these errors, and the size of the .inc files means
that clearing them up is not really an option (unless there is a simple
macro I could pass them through).
I have managed to get small surfaces (~30000 triangles) to render OK
but this only gives me a limited view of what I am trying to visualise.
Again, any further suggestions are welcomed!
I hope you all have a great xmas
Simon.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
