Well, I am convinced that MacMegaPOV has the same memory leak (or
**whatever** you want to call it, Thorsten!) that plagues the Windows
version when it comes to loading and unloading lots of large image maps
over a series of animation passes. The exact same problem happened
**AGAIN** with yet another animation job... the only difference this time
around was that I started rendering at frame 1055 and it froze after
completing frame 1117--the dreaded 63rd frame.

I'm in the middle of trying to get a project finished, but when I have some
free time I'm going to upload the files to the binaries section to prove
that what I'm seeing isn't just some figment of my imagination. Who
knows--maybe I'm doing something in the SDL that is causing WinPOV and
MacMegaPOV to slowly leak memory, and I'd be perfectly happy for Thorsten
to point out the foolish error of my ways so I can continue using
MacMegaPOV on my G5. As things stand now, though, I can't reliably use
software that buggers itself after a few dozen invocations.

Remco de Korte wrote:
>Scott Gammans wrote:
>>
>> >So there may indeed be a memory leak occurring when you render
>> >animations with POVRay that need to load a lot of images.
>>
>> Yes, that is exactly, EXACTLY the behavior I have seen in the past.
>>
>> >The solution
>> >would probably be not to reload image maps for each scene but to keep
>> >them in memory.
>>
>> Would you mind explaining what you mean by that? Is this a suggestion for
>> the POV-Ray developers for the next version of POV-Ray, or are you
>> suggestion a technique that I can implement using the SDL? And if it's the
>> latter, please provide a brief SDL example of what you are talking about.
>>
>> Many thanks...
>
>It's a solution I used in the program I mentioned. It had to load
>graphics data continuously and the only way I could solve it is to load
>everything only one time and then keep it in memory.
>For a POVRay animation render that would mean that it would keep
>imagemaps and such in memory until the end of the render instead of
>loading them for each frame, but to be honest I don't know how POVRay
>handles things now, I'm only assuming it doesn't do this already.
>
>So, obviously, this is not a solution you can achieve with the SDL. It
>may only help to know that cutting down on the image loading *might*
>help.
>
>What puzzles me is how this could occur on Mac as well though...
>When I ran into this problem and found that the cause wasn't in my own
>code (eliminating almost all of it didn't solve it) I figured that it
>was something in the way Windows (98 at the time) handles files.
>Now I think that it could also have been somewhere in between (the code
>that loads and decodes the images); I realize this seems vague, but I
>didn't get any further then that... :)
>
>Remco
>

Post a reply to this message

In article <web.3fa3b203944a788685aba4bf0@news.povray.org> , "Scott Gammans"
<deepgloathatesspamaatyahoodotcom> wrote:

> Well, I am convinced that MacMegaPOV has the same memory leak (or
> **whatever** you want to call it, Thorsten!)

As POV-Ray is able to track all memory used, and that tracking will show all
memory "Lost" and then free it anyway, there is no memory leak.  It is that
simple.  Just repeating something that sin't a fact does not make it a
fact...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <web.3fa3b203944a788685aba4bf0@news.povray.org> , "Scott Gammans"
<deepgloathatesspamaatyahoodotcom> wrote:

>  The exact same problem happened
> **AGAIN** with yet another animation job... the only difference this time
> around was that I started rendering at frame 1055 and it froze after
> completing frame 1117--the dreaded 63rd frame.

If you are so sure it ahppens with all animations, why don't you post a
scene that "shows" the problem in scene file binary group?  Please remember
to include the INI file used to render it as well!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

news:3fa3ca69@news.povray.org...

> If you are so sure it ahppens with all animations, why don't you post a
> scene that "shows" the problem in scene file binary group?  Please
remember
> to include the INI file used to render it as well!

For the record, I think there may be something fishy with the loading of
large image maps. I had a problem recently (official POV, Windows XP) with
one JPEG (9000*4500): the scene rendered OK a few times and then BLAM!,
POV-Ray returned a message saying that it couldn't load the image due to
(IIRC, didn't write it down) a pointer problem. After closing and reloading
POV-Ray, the scene ran fine again. It happened several times, but as it was
a 4000-line scene that took several minutes to parse and used 1Gb or RAM,
bug hunting wasn't exactly easy. I didn't use the map eventually and the
problem never resurfaced. I've tried to replicate it with a simpler scene
including the map, at least to write down the error message, but everything
was OK (no unusual memory consumption in successive runs).
I've also seen POV-Ray suddenly complaining about a missing image map
between 2 successful runs of the same (unchanged) script. Again, this was
impossible to replicate.

G.


-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Thorsten Froehlich wrote:
> As POV-Ray is able to track all memory used, and that tracking will show all
> memory "Lost" and then free it anyway, there is no memory leak.  It is that
> simple.  Just repeating something that sin't a fact does not make it a
> fact...
> 
How about third-party libraries, e.g. TIFF library? Are they tested 
against memory leaks (or perhaps they are used 'incorrectly', so memory 
is not freed finally)? They don't use POV-Ray memory allocation routines 
and as it seems from description, problem is related to image maps. So 
even if POV-Ray code itself does not leak, POV-Ray as whole might have 
memory leaks.

Post a reply to this message

Vahur Krouverk wrote:
> Thorsten Froehlich wrote:
> 
>> As POV-Ray is able to track all memory used, and that tracking will 
>> show all
>> memory "Lost" and then free it anyway, there is no memory leak.  It is 
>> that
>> simple.  Just repeating something that sin't a fact does not make it a
>> fact...
>>
> How about third-party libraries, e.g. TIFF library? Are they tested 
> against memory leaks (or perhaps they are used 'incorrectly', so memory 
> is not freed finally)? They don't use POV-Ray memory allocation routines 
> and as it seems from description, problem is related to image maps. So 
> even if POV-Ray code itself does not leak, POV-Ray as whole might have 
> memory leaks.

There is of course an easy way to check that - use ppm/pgm for all 
images.  These don't use external libraries.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <8ji### [at] tritonimagicode> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> There is of course an easy way to check that - use ppm/pgm for all
> images.  These don't use external libraries.

Neither does TGA.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> In article <web.3fa3b203944a788685aba4bf0@news.povray.org> , "Scott Gammans"
> <deepgloathatesspamaatyahoodotcom> wrote:
> 
> > Well, I am convinced that MacMegaPOV has the same memory leak (or
> > **whatever** you want to call it, Thorsten!)
> 
> As POV-Ray is able to track all memory used, and that tracking will show all
> memory "Lost" and then free it anyway, there is no memory leak.  It is that
> simple.  Just repeating something that sin't a fact does not make it a
> fact...
> 
>     Thorsten
> 

I agree, but evidently there is a problem somewhere. It isn't
necessarily a bug in POVRay but it is something that occurs while
rendering animations in POVRay as well as in other situations.
Saying it isn't a memory leak, true as it is, doesn't really solve the
problem. Even though the actual 'bug' (if any) isn't in POVRay it would
be nice to know how to avoid such things, either in the scene or ini
file or in the way you render things (my suggestion for Scott would be
to render it in chunks of 63 frames ;)) or maybe even in a line in the
program code somewhere.

Remco

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote

>> I know there is no memory leak big
>> enough that it could cause what you claim
>> it would - for your claim to be correct
>> POV-Ray would have to forget about tens
>> of megabytes of memory per frame!

>> As POV-Ray is able to track all memory
>> used, and that tracking will show all
>> memory "Lost" and then free it anyway,
>> there is no memory leak.

I am *so* going to enjoy watching you eat your words, you arrogant
smarty-pants.

Step 1: Render the following scene with this command line:
+H1000 +W1000 +Q0 +A0.0 +AM1 +R3 -J0.0 +FC
The output should be a 1000x1000 Targa file. Name the file imagefile.tga.

// Begin file

global_settings {
    assumed_gamma 2.0
    max_trace_level 5
}

camera {
  orthographic
 location y*100
 look_at 0
 angle 90
 right x
 up y
}

#declare Granite_Texture = texture {
    pigment {
        granite
        color_map {
            [0.0 rgb 0.5]
            [0.5 rgb 0.375]
            [1.0 rgb 0.5]
        }
        scale 12
    }
    finish {ambient 1}
}

plane {y,0 texture {Granite_Texture}}

// End of file

Step 2: Render this scene with the following command line:
+W640 +H480 +Q2 -A0.0 -J0.0 +FN +UA +KFI0001 +KFF1800
The output should be a series of 1,800 PNG frames for a 60-second animation.
But unless your workstation has unlimited memory, you will never be able to
render anywhere near 1,800 frames in one pass... POV-Ray will eventually
konk out with the following parse error:

image_pattern {tga "imagefile.tga" <----ERROR
Parse Error: Out of memory.  Cannot allocate 1000 bytes for TGA image line.

On my 2.4 GHz Pentium 4 Windows XP service pack 1 workstation with 1 GB RAM
and no other applications running, it only took 7 minutes and 19 seconds for
the parse error to occur while processing frame 465. Incidentally, the same
thing happens if you repeat this test by generating a PNG file in step one
and using that output file for the texture map in step two... with the PNG
map it took 6 minutes and 39 seconds for the parse error to occur at frame
461.

As you can see, this demonstration of the memory bug was generated
completely from within POV-Ray without the use of any external image
processing programs or any other external processing. Since Thorsten has
already stated that POV-Ray does not use any external libraries for Targa
files, it follows that there must be a memory allocation problem somewhere
within POV-Ray itself.

// Begin file

global_settings {
    assumed_gamma 2.0
    max_trace_level 5
}

camera {
 location 50
 look_at 0
 angle 90
 right image_width/image_height*x
 up y
}

#declare Test_Texture = texture {
 image_pattern {tga "imagefile.tga" map_type 2}
 texture_map {
     [0.0000 pigment {color rgb <1,0,0>} finish {ambient 1}]
     [1.0000 pigment {color rgb <0,0,1>} finish {ambient 1}]
 }
 scale 50
 rotate <90,0,-90>
}

cylinder {z*25,z*-25,10 texture {Test_Texture} rotate
<-frame_number,frame_number,frame_number/2>}

// End of file

Post a reply to this message

> I am *so* going to enjoy watching you eat your words, you arrogant
> smarty-pants.

	I'm not sure whether Thorsten should ever reply to this...

> As you can see, this demonstration of the memory bug was generated
> completely from within POV-Ray without the use of any external image
> processing programs or any other external processing. Since Thorsten has
> already stated that POV-Ray does not use any external libraries for Targa
> files, it follows that there must be a memory allocation problem somewhere
> within POV-Ray itself.

	You demonstrate nothing since you generate an animation by
outputting PNG files. If the memory leak is in the PNG library which
is used by povray, then it's still not an memory leak within povray.
You should try again by saving TGA or PPM frames, not PNG. Then please
report your corrected results so that someone can start analyzing
what's going on. I will try your scripts myself (on Linux, but that
does not matter if there is a memory leak in povray) in the light of
the rendering your animation as TGA frames.

	BTW, nobody said not to use an external image processing program.

	- NC

Post a reply to this message