Warp <war### [at] tagpovrayorg> wrote:
> ChamanSingh <nomail@nomail> wrote:
> > I just wanted to get an unbiased opinion about this topic, and looking at the
> > response, I think, we may have to re-implement PovRay type system with very low
> > memory requirements.
>
>   You won't be able to reduce the memory footprint of a mesh by any
> rational means while keeping the entire mesh in memory.
>
>   The only option would be to load only part of the mesh at a time
> (ie. only the parts which are needed). Some high-end renderers support
> this, but it's a quite complicated thing to implement. One possible
> approach is to use the octree POV-Ray already uses for meshes so that
> only those nodes which are requested are loaded, and least used nodes
> freed. It's not trivial, though.
>
> --
>                                                           - Warp

Personally, I've long considered pov to have a low memory footprint anyway.
There is one thing that this post reminded me of, though.  This is applies to
running povray under windows using the GUI - open documents do take up more
memory.  I've dealt with some a fairly large meshes, something like ~8Mb when
saved as an include by itself.  If you have the document open in one of the
tabs, it does take up that extra bit of RAM.  In this case, when we are talking
about terabytes, an analogous concept could be used by splitting the large
mesh(es) into smaller chunks, then loading and rendering only the visible
portions of the mesh, or even splitting the image into chunks and rendering
each chunk separately.

  Personally, I am kind of curious as to what type of data this is.  If a mesh
that dense is completely within the camera view, the resolution required to
tell the difference between that mesh and another with 1/100th of the triangles
must be very high.  If not all of the mesh is visible, then it can be split into
pieces.

-Reactor

Post a reply to this message