![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <38576D07.7DFB478E@bbsrc.ac.uk>, sim### [at] bbsrc ac uk
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
With very big files like this I've found that restarting windows helps.
Mick
Mario Splivalo <msp### [at] jagor srce hr> wrote in message
news:MPG.12c19024acb6a6c2989684@news.povray.org...
> In article <38576D07.7DFB478E@bbsrc.ac.uk>, sim### [at] bbsrc ac uk
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ken <tyl### [at] pacbell net> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nathan Kopp wrote:
>
> Ken <tyl### [at] pacbell net> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ken <tyl### [at] pacbell net> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nathan Kopp <Nat### [at] kopp com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
You might try throwing some switches off if you haven't already.
-GW for one will turn off the errors in the message stream.
Then there's -UV for vista buffer but the thing to probably try is using
'hierarchy off' inside a 'mesh' of your triangles and see if that helps
(memory-wise anyway).
Bob
"Simon Andrews" <sim### [at] bbsrc ac uk> wrote in message
news:3860AF2A.410A80FF@bbsrc.ac.uk...
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Could you publish the source on p.t.s.? I could try to run it (NT4; 386 MB)
to see whether this makes any difference...
--
Regards,
Sander
Simon Andrews <sim### [at] bbsrc ac uk> schreef in berichtnieuws
38576D07.7DFB478E@bbsrc.ac.uk...
> 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
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |