 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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,
See my last posts.
Just render this single line in an animation loop :
#declare T=texture{image_pattern {jpeg "anyfile"} texture_map {[0
pigment{rgb 0}][1 pigment{rgb 1}]}}
Just for the fun I justed tested it with "anyfile" being a 10000 x 5000
white jpeg and I ran out of memory in frame 3.
G.
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3fa6c85b944a788685aba4bf0@news.povray.org> , "Scott Gammans"
<deepgloathatesspamaatyahoodotcom> 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 think I already responded to this in:
Date: Thu, 30 Oct 2003 00:56:21 +0100
From: "Thorsten Froehlich" <tho### [at] trf de>
Newsgroups: povray.macintosh
Subject: Re: OS X 10.2
Message-ID: <3fa053a6$1@news.povray.org>
Xref: news.povray.org povray.macintosh:1234
<http://news.povray.org/povray.macintosh/33564/235928/>
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris,
See my previous demonstration post. The problem occurs no matter what type
of output is selected...
**including Targa**.
"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 Cason
> POV-Team co-ordinator
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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. When I generated a PPM file in
step one of my demonstration test and tried to use the outputted file
imagefile.ppm in step two, I got the following parse error:
image_pattern {ppm "imagefile.ppm" <----ERROR
Parse Error: Unsupported number of colors (0) in PPM image.
> 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? 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.
"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:fo4### [at] tritonimagicode...
> Scott Gammans wrote:
> >
> > 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?
>
> There is no point in trying to investigate in a problem if it does not
> exist in the current code.
>
> > 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.
>
> Which is exactly the point i was trying to make. If there is a memory
> problem in the png library this is something completely different. You
> can either use a different file format or try to get a libpng programmer
> fix it. I doubt anyone here will bother to dig into libpng internals.
>
> Disclaimer: i have no idea if there indeed is a memory problem with png
> writing or not.
>
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
