 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>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 ...
Since you have never--not even once--been helpful to me in the past, your
empty threat is meaningless to me. Nonetheless, I should not have stooped
to name-calling and apologize for that.
>Memory leak debugging was enabled for this render, and not a single leak was
>found.
Again (as with Cristoph) it sounds like you're using a development version
of POV-Ray and not the general release version that the rest of us are
using. If so, that's not a valid basis for comparison. And if you're using
a debug build of POV-Ray that includes debugger information, that's
*really* not a valid comparison. I have often run into problems in the past
that never occurred with executables that were linked with debug libraries
but only with the release build of a program.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 3 Nov 2003 16:28:31 EST, "Scott Gammans"
<deepgloathatesspamaatyahoodotcom> wrote:
> If you're not going to use the generally-released version ...
We (variety of developers associated to pov) are not in industry/business
supported development. We are hobbist who share their development environments
with own companies, families and other purposes. We have limited resources
with no abbility to verify _everything_ but we do our best to make it better.
We have 3.5.1 on board which will be ready in the near future. We are
concentrated on it very much and there were already several bugs fixed. It is
possible that your problem is side effect of other bug but as 3 different
persons verified it can't be replicated. It suggests it does not exist anymore
in latest development version which is a very good information itself for us
because it does not slow down 3.5.1 release.
In general I appreciate users obstinacy in tracking down bugs and working
myself with other packages I know it is not an easy task from user point of
you but definietly you are using bad wording sometimes. Thanks in advance for
fixing it and in the future please use povray.off-topic for discussions
related to humanity.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
news:3fa7ced2$1@news.povray.org...
> Confirmed on my PIII, NT4. Actually I just ran it at 160*120 with no file
> output.
And yes, it looks that it's fixed on the current development vesion I have.
G.
--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
