I tried to render a Scene with to new Bounding Method 2, but the
construction of the BSP stops after ~520k BSP-Nodes with the following
Errormessage:

"Out of memory! There is not enough memory available for
POV-Ray to complete a task. Usually this suggests the scene
you are trying to render is too complex for your hardware
to handle. Refer to the platform-specific documentation for
details, it might contain hints how to work around this.

Out of memory! There is not enough memory available for
POV-Ray to complete a task. Usually this suggests the scene
you are trying to render is too complex for your hardware
to handle. Refer to the platform-specific documentation for
details, it might contain hints how to work around this.

Render failed"

I don't think the this is a real Out of Memory Error, because POV 3.7 Beta
18 uses round about 820MB Memory, and there are 670 MB left (real RAM, no
Virtual Memory).

The Error occurs with both the normal and the SSE2 Build.
The OS used is Win XPP SP 2.

The Scene did not use any "Special Effekts" like Media or Radiosity.
With the old Bounding Method there is no Problem wiht this Scene.

Here you can get the Scene:

blue.unix-ag.uni-hannover.de/~schwanck/Download/Pov37BetaTest/Felswand_3.7_Betatest.zip

-- Thomas

Post a reply to this message

Schwan379 wrote:
> I don't think the this is a real Out of Memory Error, because POV 3.7 Beta
> 18 uses round about 820MB Memory, and there are 670 MB left (real RAM, no
> Virtual Memory).

I've tested this with your scene and in fact it is a genuine memory error;
due to the way the STL (a library we use) works, it attempts to allocate a
very large array to move an existing array that it needs to expand, and this
is what is failing (the request is for hundreds of megabytes).

You will need to experiment with different BSP settings to get this to work -
at the time of the alloc failure, here at least, the BSP depth was 33. I
tried 25 and had a successful render, though it was slower than non-BSP
bounding due to the large average number of objects at each leaf node.

I suggest not only changing the max depth, but also experimenting with some
other BSP constants to see if you can get a better tree layout (see the
release notes for settings information).

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> I've tested this with your scene and in fact it is a genuine memory error;
> due to the way the STL (a library we use) works, it attempts to allocate a
> very large array to move an existing array that it needs to expand, and this
> is what is failing (the request is for hundreds of megabytes).

  Is this the case with std::vector?

  You should consider using std::deque instead, or an implementation of the
same idea.
  In a work project I actually had the exact same problem: I used std::vectors
for the main data containers, items were continuously being added to these
vectors, and they consumed a lot more memory than expected. I discovered
this one day when I measured the memory consumption of the program and
compared it to the theoretical minimum that it must take to work: The
real consumption was almost twice bigger!
  I immediately knew that the problem was with std::vector. I implemented
my own vector data container which used the same idea as std::deque uses,
but simplified, and the memory consumption immediately dropped dramatically,
and got much closer to the theoretical minimum. The speed of the program
did not suffer at all.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> I've tested this with your scene and in fact it is a genuine memory error;
>> due to the way the STL (a library we use) works, it attempts to allocate a
>> very large array to move an existing array that it needs to expand, and this
>> is what is failing (the request is for hundreds of megabytes).
> 
>   Is this the case with std::vector?

While the algorithm does indeed use std::vector, the behavior you are
referring to is not the effect being observed. The available memory is
already depleted due to the recursive nature of BSP building. While it is
possible modify the algorithm to perform a much more complex building which
is also somewhat faster, that code is of the unreadable kind (because it can
use the fact that some internal data structures are already partially sorted).

Either way, when it then comes to building the BSP object list (which needs
to be resized), the available 32-bit memory space is simply too fragmented
to extend it (even though it can potentially happen that enough space is
left in the sum of fragments). Two practical solutions exists to solve this
limitation with the standard algorithm implementation: Either have a 64-bit
address space (such that fragmentation does not matter as much), or split
the BSP tree into subtrees. Naturally, I prefer the later, but the former
will work with POV-Ray 3.7 on 64-bit systems really well, while the later
method will not be implemented in _3.7_.

	Thorsten

Post a reply to this message