|
|
Came across this while running some animation in v3.6.1 on Windows XP (I haven't
yet switched to the new version--my animation scene is months in the making, and
I don't want to make the switch until it's all done and rendered.) I'm wondering
if this has already been fixed, either in v3.6.2 or one of the betas.
With an image_map for a pigment, as well as a quick_color statement (and using a
Quality setting that invokes quick_color), every new frame of animation shows a
progressivly climbing 'peak memory used' in the messages. The used memory
continues to climb until an out-of-memory fatal error occurs. How long it takes
for that to happen depends on the file size of the image_map. (The memory
increase is directly related to that.) By commenting-out quick_color, the
problem disappears. Ditto if you run the animation at a Quality above the
quick_color kick-in. (BTW, a jpeg image_map seems to show its *uncompressed*
file size in 'peak memory used'; I guess that's correct?)
I haven't seen anything in the docs (yet) that precludes using quick_color with
an image_map, so I assume it's OK.
After discovering this problem, I did a search of the newsgroups (and the beta
fixes), and the only related thing I see is a post from the days before v3.6,
which may or may not be related...
http://news.povray.org/povray.programming/thread/%3C40127c21%40news.povray.org%3E/?mtop=6
Here's some quick animation test code; run ten frames and check the 'peak memory
used' afterward, for each frame. #Declaring the texture first doesn't alter the
behavior. (BTW, the last message for frame 10 is duplicated twice--unrelated to
this problem. Should POV-Ray be doing that?)
test code:
camera {
location <.5, 2, -10>
right x*image_width/image_height
look_at <.5,1,0>
angle 39
}
box{0,1
texture {
pigment{
image_map {sys "my_image.bmp"} // use any image and file type
quick_color rgb <1,.7,.5>
}
finish {
ambient .15
diffuse .4
}
}
}
Post a reply to this message
|
|