I'm making a fractal object built from spheres and cones, and my
laptop (500MB RAM) is unable to handle anything more than 5
levels of recursion. Is there any way of reducing the amount of
memory povray uses to construct the object? I figured out how
to get rid of the recursive macro to reduce parsing time (use an
array, the elements of which reference each other to implicitly
create a recursive object), but it seems that povray still has to
explicitly instantiate all the objects at the end of the parsing
stage. At 6 levels of recursion, this last stage causes my poor
laptop to thrash like crazy and basically make no progress.
(There are 12^n constituent objects in the fractal, where n
is the recursion level, so this thing grows pretty dang fast.)

Is there any way to control POV's resource usage patterns or
is the only solution to buy more RAM? Thanks.

Post a reply to this message

quickfur wrote:
> I'm making a fractal object built from spheres and cones, and my
> laptop (500MB RAM) is unable to handle anything more than 5
> levels of recursion. Is there any way of reducing the amount of
> memory povray uses to construct the object?

Sphere and cones are already as small as they can get. The most successful
approach when dealing with recursive structures is to not create objects
that won't be visible.

> Is there any way to control POV's resource usage patterns

You already are in control: Create fewer objects. POV-Ray can hardly do
anything about objects you create. It cannot ignore them for obvious
reasons. Thus, they need to be stored somewhere in memory.

	Thorsten

Post a reply to this message

Additional instances of meshes are supposed to be much cheaper than that of
CSG.  I think another thing is to try to have a common texture applied to a
union rather than individually instantiated.

Post a reply to this message

"Charles C" <nomail@nomail> wrote:
> Additional instances of meshes are supposed to be much cheaper than that of
> CSG.  I think another thing is to try to have a common texture applied to a
> union rather than individually instantiated.

I already did that. At first my scene used a recursive #macro that
created every object individually, complete with their own textures.
This sucked up a lot of memory, so I moved the common textures
into a #declare, which helped a bit. Then I replaced the leaf objects
with a #declare as well, since they were all the same. Then I
realized that all the sub-objects of a particular level were identical,
so instead of a macro, I used a simple while-loop to create the object
from bottom-up in an array, with subsequent array elements
referring to the previous ones. This drastically reduced parsing
time (from a few minutes to basically instantaneous). Memory
usage is also slightly reduced, but at the end of the parsing stage,
povray starts thrashing---I suspect this is when POV is actually
instantiating the object from the array.

Perhaps the only solution is to buy more memory. :-S  I was just
wondering if there are ways to, e.g., turn off bounding slabs and
such (I don't mind waiting longer for the render). Maybe this is
just not possible with 500MB RAM. :-P

Although, on second thoughts, the objects *are* all in one
gigantic CSG union ('cos I'm too lazy to calculate the position
and orientation of every single sub-object individually). I'll try
to individually place objects and see if that helps.

As for omitting unseen objects, most of the objects are seen,
unfortunately. It looks sorta like a 3D snowflake, with plenty
of gaps in between to see what's behind. 12^n is a very fast
growing number, though... maybe I'm just hoping for the
impossible.

Post a reply to this message

Charles C wrote:
> Additional instances of meshes are supposed to be much cheaper than that of
> CSG.

The original poster did not talk about CSG. Besides, even the instance of a
mesh object will consume more memory than a sphere or a cone...

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> Charles C wrote:
>> Additional instances of meshes are supposed to be much cheaper than that of
>> CSG.
> 
> The original poster did not talk about CSG. Besides, even the instance of a
> mesh object will consume more memory than a sphere or a cone...
> 
> 	Thorsten

Assuming there is some level of symmetry in the object, he could save 
memory by creating a mesh of a portion of the object (say, 1 branch of 
his fractal) and replicate that many times.

Obviously, just replacing each individual sphere / cone with its own 
mesh wouldn't solve anything.  He'd have to have a mesh encompass as 
much as possible of the object to get maximal savings; how large he can 
make the mesh is highly dependent on his particular fractal.

...Chambers

Post a reply to this message

Ben Chambers <ben### [at] pacificwebguycom> wrote:
> Thorsten Froehlich wrote:
> > Charles C wrote:
> >> Additional instances of meshes are supposed to be much cheaper than that of
> >> CSG.
> >
> > The original poster did not talk about CSG. Besides, even the instance of a
> > mesh object will consume more memory than a sphere or a cone...
> >
> >  Thorsten
>
> Assuming there is some level of symmetry in the object, he could save
> memory by creating a mesh of a portion of the object (say, 1 branch of
> his fractal) and replicate that many times.

Hmm, I didn't know this. I'm not sure if it will be easy enough to
convert the current object into a set of meshes, but I'll have to try
that next time. It seems that the best solution right now is still just
to buy more RAM. :-)

> Obviously, just replacing each individual sphere / cone with its own
> mesh wouldn't solve anything.  He'd have to have a mesh encompass as
> much as possible of the object to get maximal savings; how large he can
> make the mesh is highly dependent on his particular fractal.
[...]

It's the one shown here:

http://news.povray.org/povray.binaries.images/thread/%3Cweb.45c3ceb3e8130f30dd5364bf0%40news.povray.org%3E/

Post a reply to this message