"Chris Cason" <new### [at] deletethispovrayorg> wrote in message
news:3fa7d2dd@news.povray.org...
> If you would be willing to post a sample scene that is guaranteed
> to cause the problem in the official POV-Ray for Windows v3.5 on your
> system, I will look into this, so as to settle the matter of whether
> it exists or not.

Chris: Just so you don't have to go back through the replies in this thread
to find my demonstration test, I'm reposting the memory bug demo here.

Please note: I've changed the test in step two to also use Targa for the
output, to address several people's complaints that my first demo used PNG
for the animation output files. The demo now uses nothing but Targa files
for the input and output files. Since--according to Thorsten--Targa file
generation does not use any external libraries, this proves that the memory
allocation bug lies within the general release version 3.5 of POV-Ray.

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 +FC +UA +KFI0001 +KFF1800
The output should be a series of 1,800 TGA 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.

// 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

Thank you for confirming that I was right about the memory bug, Gilles.

"Gilles Tran" <tra### [at] inapginrafr> wrote in message
news:3fa7ced2$1@news.povray.org...

> message de news:3fa681ab$1@news.povray.org...
>
> > 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.
>
> Confirmed on my PIII, NT4. Actually I just ran it at 160*120 with no file
> output.
> With 50 frames, the peak memory used reported by POV-Ray for the first
frame
> was 3165096 bytes and 154489167 for the last one = 50 x 3 Mb... It just
> doesn't release the memory used when loading the image. I've tried with
TGA,
> JPG and PNG.
>
> I suspect that the culprit is the image_pattern statement (or
> pigment_pattern{image_map{}} as it happens with this too). It doesn't
happen
> with a regular image_map{}.
> This explains both why I couldn't replicate it at first (I had tested the
> problem only with image_map) and why I had similar trouble with large
maps,
> since I'm using image_pattern a lot.
>
>
> G.
>
>

Post a reply to this message

In article <3fa80665$1@news.povray.org> , "Scott Gammans" 
<dee### [at] yahoocom> wrote:

> Well, I found *another* possible POV-Ray bug when I tried my demonstration
> test using PPM for the image map. POV-Ray (at least v3.5 on Windows) appears
> to generate PPM files using binary encoding, and can't read its own output
> files when used for input image map files.

I suppose you are talking about this one?

Return-Path: <new### [at] netplexaussieorg>
To: bug### [at] povrayorg
Newsgroups: povray.bugreports
Subject: ppm bug
From: ingo <ing### [at] tagpovrayorg>
User-Agent: Xnews/5.04.25
Date: 28 Dec 2002 10:16:11 -0500
Message-ID: <3e128be2@news.povray.org>
Xref: news.povray.org povray.bugreports:634

    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 <3fa80665$1@news.povray.org> , "Scott Gammans" 
<dee### [at] yahoocom> wrote:

> And it does nothing to verify my proof that the current
> version of POV-Ray has a memory problem with loading image maps over and
> over again in long-running animation sequences, which Thorsten has flatly
> stated is untrue.

Gilles confirmed that he can see problems with image_pattern /
pigment_pattern in the current 3.5 binary but not with all image_maps as you
say.  Also, as you implied this bug has existed for a long time in the
Windows version, but as both features are new in 3.5, this cannot really be
that long ago.

In conclusion, just following the bug reporting guidelines and posting a
small scene together with the report rather than an extensive speculation
would probably have given a solution in this thread much more quickly.

    Thorsten

Post a reply to this message

Yes, and your repeated vehement assertions that I was full of it certainly
sped things along.

Thorsten Froehlich wrote:
>Gilles confirmed that he can see problems with image_pattern /
>pigment_pattern in the current 3.5 binary but not with all image_maps as you
>say.  Also, as you implied this bug has existed for a long time in the
>Windows version, but as both features are new in 3.5, this cannot really be
>that long ago.
>
>In conclusion, just following the bug reporting guidelines and posting a
>small scene together with the report rather than an extensive speculation
>would probably have given a solution in this thread much more quickly.
>
>    Thorsten

Post a reply to this message

Scott Gammans wrote:
>>There is no point in trying to investigate in a problem if it does not
>>exist in the current code.
> 
> 
> Could you please explain that statement? If there is a problem in the
> binaries that are out in the field, what good is it to test a reported bug
> in your development code (source code to which common users do not have
> access)? Sure, it proves that the next version of POV-Ray won't have the
> problem, but until *we* have the new version, it doesn't do us users much
> good, does it?

The current code is more or less what will be the next official version 
that will be released.  It does not suffer from the problem so this is 
as much as what can be done for the users.  Looking into the 3.5 code to 
find the original problem will not change anything about this - you will 
still have to wait for the next release to have this fixed in official 
POV-Ray.

If we now all start looking where exactly the problem is and how it 
could be fixed although it already is this would only delay work on the 
next POV-Ray version - i don't think this is in the interest of you or 
any other user.

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