I've been getting 'Fatal error in renderer: Out of Memory' recently in a 
few of my scenes (in 3.7b31, both in Windows and Linux)
The same files run fine in 3.6 (Official 3.6.1c and MegaPOV 1.2.1), so I 
assume this is a bug.
I traced it down to a very simple scene file that produces the error, 
trying to remove everything that doesn't apply (no normals, no 
radiosity, no finishes, etc).

Example code that throws error:
--------------------------------------------------------
#local rows=9;
#local cols=8;
#local di=1;
#local dj=1;
#local i=0;
#while (i<rows)
	#local j=0;
	#while (j<cols)
		light_source{<i*di,19,j*dj> color rgb 1 spotlight radius 10 falloff 20 
point_at <i*di,0,j*dj>}
		#local j=j+1;
	#end
	#local i=i+1;
#end
box{<-6,0,-6>,<rows*di+6,20,cols*dj+6>
	hollow texture{pigment{rgb 0.025}}
}
box{<-7,-1,-7>,<rows*di+7,21,cols*dj+7>
	pigment{rgbt 1} hollow
	interior{media{
		absorption 1
//		emission 1
//		scattering{2,1}
		density{ rgb 0.001}}}
}
camera{location<-5,5,-5> look_at<rows/2*di,0,cols/2*dj>}
--------------------------------------------------------

This fails with the out of memory error beta versions:
3.7.0.beta.31.msvc9-sse2.win32
3.7.0.beta.31 linux (built from latest available *nix source)

The scene renders fine with all variation of 3.6 (mac + win tested)

Decreasing the numbers of rows or columns will make it run, I just 
played with it until it failed with the fewest number of light sources. 
Increasing the distance between lights (di and dj) will make it run as 
well, but if the number of rows or cols are then increased it will fail. 
This happens with any size render, with or without preview.

Hope this provides enough info, and I hope I'm not bringing up something 
that you've already heard too much about.

cshake

Post a reply to this message

CShake <cshake+pov### [at] gmailcom> wrote:
> I've been getting 'Fatal error in renderer: Out of Memory' recently in a
> few of my scenes (in 3.7b31, both in Windows and Linux)

As you've found, it's seemingly triggered by the large number of lights traced
through media in the scene, not media properties directly.

It looks like one of the calls to std::sort in
MediaFunction::ComputeMediaLightInterval is causing a bad_alloc exception to be
thrown, probably due to the use of a fixed number of elements (64) for
LightSourceEntryVector and friends. I haven't spent much time on this but there
are lots of FIXME comments associated with this fixed size so presumably this is
a known (or anticipated) issue.

Doubling the fixed array size universally allows the scene to render, until the
number of lights in the array is doubled in the scene file which brings back
the problem again.

Tom

Post a reply to this message

"Tom York" <alp### [at] zubenelgenubi34spcom> wrote:
> CShake <cshake+pov### [at] gmailcom> wrote:
> > I've been getting 'Fatal error in renderer: Out of Memory' recently in a
> > few of my scenes (in 3.7b31, both in Windows and Linux)
>
> As you've found, it's seemingly triggered by the large number of lights traced
> through media in the scene, not media properties directly.
>
> It looks like one of the calls to std::sort in
> MediaFunction::ComputeMediaLightInterval is causing a bad_alloc exception to be
> thrown, probably due to the use of a fixed number of elements (64) for
> LightSourceEntryVector and friends. I haven't spent much time on this but there
> are lots of FIXME comments associated with this fixed size so presumably this is
> a known (or anticipated) issue.
>
> Doubling the fixed array size universally allows the scene to render, until the
> number of lights in the array is doubled in the scene file which brings back
> the problem again.
>
> Tom

Was this ever fixed/corrected/worked around/something-or-other in b32?

I have a scene with a single (area-)light, no media but a whole bunch of objects
(~2500) which renders fine until I make them transparent - at which point I get
that same "out of memory error".

Which I searched on and found this thread...

(By ~2000 or so pretty much every computer in the known universe understood how
to use virtual memory and I thought messages like "out of memory" were an
archaic artifact of the bad old days. In a sense this error message is making
me feel young again... ;-)

Post a reply to this message

"Tom York" <alp### [at] zubenelgenubi34spcom> wrote:
> CShake <cshake+pov### [at] gmailcom> wrote:
> > I've been getting 'Fatal error in renderer: Out of Memory' recently in a
> > few of my scenes (in 3.7b31, both in Windows and Linux)
>
> As you've found, it's seemingly triggered by the large number of lights traced
> through media in the scene, not media properties directly.
>
> It looks like one of the calls to std::sort in
> MediaFunction::ComputeMediaLightInterval is causing a bad_alloc exception to be
> thrown, probably due to the use of a fixed number of elements (64) for
> LightSourceEntryVector and friends. I haven't spent much time on this but there
> are lots of FIXME comments associated with this fixed size so presumably this is
> a known (or anticipated) issue.
>
> Doubling the fixed array size universally allows the scene to render, until the
> number of lights in the array is doubled in the scene file which brings back
> the problem again.
>
> Tom

Was this ever fixed/worked around/eliminated for b32?

I just found this message because I was searching on an "out of memory" error
for a scene with an area light and a lot of semi-transparent objects ...

Post a reply to this message

"Sven Geier" <.sven.at.sgeier.dot.net.nospamplease> wrote:
> Was this ever fixed/worked around/eliminated for b32?
>
> I just found this message because I was searching on an "out of memory" error
> for a scene with an area light and a lot of semi-transparent objects ...

As far as I remember the fixed length light source array only affected media.
I've no idea at all if it was fixed in later betas. If this problem you talk
about happens with the latest beta and does not involve media, then I suggest
submitting a minimal scene showing the problem as a new thread.

Tom

Post a reply to this message

Ah! got also this renderer out of memory, with media (using the smokegen 
macro by Mikael Carneholm), and with beta 33.

Thomas

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> Ah! got also this renderer out of memory, with media (using the smokegen
> macro by Mikael Carneholm), and with beta 33.
>
> Thomas

To the minimalscenemobile!

Post a reply to this message

"Tom York" <alp### [at] zubenelgenubi34spcom> schreef in bericht 
news:web.4a89d5bb49c22c47d55e4a40@news.povray.org...
> To the minimalscenemobile!

Yep. I shall boil something down. Already corrected the (ancient) macro to 
method 3 and intervals 1, but still happens. I shall come with something to 
test soon.

Thomas

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> schreef in bericht 
news:4a8abe4f$1@news.povray.org...
>
> "Tom York" <alp### [at] zubenelgenubi34spcom> schreef in bericht 
> news:web.4a89d5bb49c22c47d55e4a40@news.povray.org...
>> To the minimalscenemobile!
>
> Yep. I shall boil something down. Already corrected the (ancient) macro to 
> method 3 and intervals 1, but still happens. I shall come with something 
> to test soon.


...problem is: I cannot get the error again, try what I may... :-(
I leave it for now. My impression tentatively is that my settings for 
smokegen.

Thomas

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> "Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> schreef in bericht
> news:4a8abe4f$1@news.povray.org...
> >
> > "Tom York" <alp### [at] zubenelgenubi34spcom> schreef in bericht
> > news:web.4a89d5bb49c22c47d55e4a40@news.povray.org...
> >> To the minimalscenemobile!
> >
> > Yep. I shall boil something down. Already corrected the (ancient) macro to
> > method 3 and intervals 1, but still happens. I shall come with something
> > to test soon.
>
>
> ...problem is: I cannot get the error again, try what I may... :-(
> I leave it for now. My impression tentatively is that my settings for
> smokegen.
>
> Thomas

I'll have a look at the latest source available to me to see if the issue I saw
before has been addressed; I'm well behind the official source now anyway, so
it's a good excuse.

Still, no guarantees; the windows source is apparently on beta 32, so it could
easily have been fixed in 33 or 34 and the reason behind what you're seeing
could be something different.

Tom

Post a reply to this message