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] bbsrcacuk> 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

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] bbsrcacuk> 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