Le_Forgeron wrote:

> We are, with 65 planes, pushing too many interiors

ah makes sense. I originally had the problem with disc object
AFAIK that also has an "half-infinite" interior.

> Work around for your scene: flip the z vector (plane { -z, 0 } instead
> of plane { z, 0 }

It was just a test, the final scene used stacked
tori anyway, and then not more than 20 ;)

Thanks for looking into it.

Post a reply to this message

> typedef FixedSimpleVector<Interior *, 64>  RayInteriorVector;

Seems like the error message could be better. Right now it implies that 
the user should go out and buy more RAM. Maybe something like "Exceeded 
maximum array size of 64"? Would be great if it used the word "Interior" 
as well, but that's probably not easy/possible given the templating.

  - Slime

Post a reply to this message

On 20/10/2010 15:55, Slime wrote:
>  > typedef FixedSimpleVector<Interior *, 64>  RayInteriorVector;
> 
> Seems like the error message could be better. Right now it implies that 
> the user should go out and buy more RAM. Maybe something like "Exceeded 
> maximum array size of 64"? Would be great if it used the word "Interior" 
> as well, but that's probably not easy/possible given the templating.

Currently the exception thrown in the code indicates an out-of-memory
condition as has been noted; whether or not having a special case for
hitting internal limits like this would clutter things up too much I can't
say yet. I'll have a look and see.

-- Chris

Post a reply to this message

On 19/10/2010 21:03, Christian Froeschlin wrote:
> I seem to be hitting a wall when stacking more than 64
> transparent objects ("Fatal error in renderer: Out of memory").
> The actual memory used by the process was only a few MB. Also,
> it doesn't help to set "max_trace_level" to a larger value,
> but AFAIU passing through transparency without reflection no
> longer adds to the trace level in 3.7 anyway (using beta 39).

As others have noted, this is a case of the fixed vector hitting its limit.
It's an issue we have yet to come to a better solution for. Fundamentally
we use a fixed-size vector there to force allocation of the object's
storage on the stack. Originally we had a standard vector and the
performance was terrible, both because of allocation strategy (though that
can be mitigated somewhat), and because if we allocate anything from the
heap during rendering it requires use of a mutex (this is within the RTL
heap code), which also damages performance.

We need to look at possible alternatives for this approach that allows
flexibility while [1] keeping memory usage down, [2] avoiding use of
mutexes, and [3] avoiding the need to copy memory (e.g. if the vector
storage is re-sized). [1] and [3] are generally contradictory. We might
eliminate [3] if we don't use a vector, but I'd have to look at the code to
determine if it requires contiguous layout of the data and/or if
indirection in element lookups would impact performance.

-- Chris

Post a reply to this message