 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] triton imagicode> , 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Scott Gammans wrote:
> [...]
>
> I am *so* going to enjoy watching you eat your words, you arrogant
> smarty-pants.
I think you should watch your language - personal insults are not
appropriate here.
> Step 1: Render the following scene with this command line:
> [...]
I am currently rendering around frame 800 and did not make any strange
observations yet. I doubt there will be any. Only change made is
setting output file type to ppm (+fp). I am using the current
development version and not POV 3.5 but that does not make much
difference probably.
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 <3fa681ab$1@news.povray.org> , "Scott Gammans"
<dee### [at] yahoocom> wrote:
> I am *so* going to enjoy watching you eat your words, you arrogant
> smarty-pants.
Thank you very much, I will remember this and hold it against you next time
you report some nonsense and make me waste my time ...
Other than the constantly growing message log (2.7 MB total), it rendered
just fine for me. I should have remembered to turn off the preview image, I
guess (on by default on my configuration), then it would have been faster.
Memory leak debugging was enabled for this render, and not a single leak was
found.
Thorsten
Render Statistics
Image Resolution 640 x 480
----------------------------------------------------------------------------
Pixels: 552960000 Samples: 552960000 Smpls/Pxl: 1.00
Rays: 552960000 Saved: 0 Max Level: 1/5
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Cone/Cylinder 82781005 23609585 28.52
Bounding Box 134071055 82781005 61.74
Vista Buffer 554313430 235257260 42.44
----------------------------------------------------------------------------
Calls to Noise: 0 Calls to DNoise: 18000
----------------------------------------------------------------------------
Smallest Alloc: 36 bytes
Largest Alloc: 38432 bytes
Peak memory used: 3315685 bytes
Total Scene Processing Times
Parse Time: 0 hours 7 minutes 15 seconds (435 seconds)
Photon Time: 0 hours 0 minutes 0 seconds (0 seconds)
Render Time: 1 hours 8 minutes 32 seconds (4112 seconds)
Total Time: 1 hours 15 minutes 47 seconds (4547 seconds)
____________________________________________________
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet wrote:
> I'm not sure whether Thorsten should ever reply to this...
I'll grant you that calling him an arrogant smarty-pants only lowered myself
towards his level. From day one he has never been anything but rude and
nasty whenever he's answered a question of mine in these newsgroups, but I
shouldn't have used that as an excuse for name-calling.
> 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're partially right; I should have kept the inputs and outputs pure TGA.
I used PNG for the final output because I was used to using that format for
my final output. Tomorrow I'll repeat the test using Targa output for the
animation test in step 2.
*However*... even if the leak is in the PNG library used by POV-Ray, it's
still a leak in POV-Ray. To an end user like me, it doesn't matter whether
the leak is in a subsystem used by POV-Ray or in the code code itself--it's
still a memory leak that occurs when POV-Ray is used in the manner for
which it was designed.
> BTW, nobody said not to use an external image processing program.
I only pointed that out to stress that nothing outside of POV-Ray (and
whatever libraries it uses) was involved.
Thanks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
>I think you should watch your language - personal insults are not
>appropriate here.
Granted. But since Thorsten has never felt bound by such niceties, I'm not
going to lose any sleep over it.
>I am currently rendering around frame 800 and did not make any strange
>observations yet. I doubt there will be any. Only change made is
>setting output file type to ppm (+fp). I am using the current
>development version and not POV 3.5 but that does not make much
>difference probably.
If you're not going to use the generally-released version of POV-Ray that's
available to the user community, that's not a valid basis for comparison,
is it? And if the problem truly is in the PNG library subsystem, rendering
with ppm does nothing but confirm that the problem isn't in ppm. Why didn't
you run the test exactly the way I described it, using the general release
of POV-Ray 3.5?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
