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