 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] yahoo com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
