 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm not sure if this is a POV-Ray/Macintosh or MacMegaPOV problem, so I'll
try here first.
I am trying to run a rather long animation job (750 frames) on my G5
workstation (OS X 10.2.7, *not* Panther) using MacMegaPOV Carbon 1.0, and
without fail the job poops out after rendering 63 frames. I have the start
and end frames set to 638 and 1388 respectively, but after 63 frames
MacMegaPOV crashes and dies.
I learned a long time ago on the Windows version of regular (unpatched)
POV-Ray to not run a long animation batch inside POV-Ray because it doesn't
release the memory it allocates before starting another frame. Instead, I
run POV-Ray from the command line and feed it one frame at a time, thereby
ensuring that POV-Ray releases any allocated memory as it exits after
rendering each frame (my model uses a *lot* of texture, image and bump maps
and consumes 500+ MB of memory to render 1 frame). But since there is no
command line in Macintosh, I don't see any other alternative than to run
animation jobs inside MacMegaPOV.
Any suggestions??
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 30 Oct 2003 11:53:09 -0500, "Scott Gammans"
<dee### [at] yahoo com> wrote:
> Any suggestions??
Waiting for MacMegaPOV maintainer, I would suggest as follow:
Try it again with no other software run. Does it stop each time on pure OS?
If yes try to make as minimal as possible your scene when this behaviour
occur. If you have any access to other platform (you mentioned Windows) try to
run your scene there with WinMegaPOV. Describe your results then.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3fa141f5$1@news.povray.org> , "Scott Gammans"
<dee### [at] yahoocom> wrote:
> I learned a long time ago on the Windows version of regular (unpatched)
> POV-Ray to not run a long animation batch inside POV-Ray because it doesn't
> release the memory it allocates before starting another frame.
This simply is incorrect, but I know you don't care that I tell you. Still,
incorrect information posted tends to stick in new users' minds longer than
correct information, so if nobody says it isn't so they will take it as
true...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Scott Gammans wrote:
> I'm not sure if this is a POV-Ray/Macintosh or MacMegaPOV problem, so I'll
> try here first.
>
> I am trying to run a rather long animation job (750 frames) on my G5
> workstation (OS X 10.2.7, *not* Panther) using MacMegaPOV Carbon 1.0, and
> without fail the job poops out after rendering 63 frames. I have the start
> and end frames set to 638 and 1388 respectively, but after 63 frames
> MacMegaPOV crashes and dies.
Does it crash always after 63 frames even if you render a different
subset or even identical frames? Try removing all uses of MegaPOV
features and render with official POV.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Scott Gammans <dee### [at] yahoocom> wrote:
> I am trying to run a rather long animation job (750 frames) on my G5
> workstation (OS X 10.2.7, *not* Panther) using MacMegaPOV Carbon 1.0, and
> without fail the job poops out after rendering 63 frames. I have the start
> and end frames set to 638 and 1388 respectively, but after 63 frames
> MacMegaPOV crashes and dies.
I can not give you an answer right now but I will start such an
animation an see what it does.
Is it something you can repeat or is it with one specific scene?
If so, send that scene to me if that is possible for you.
> I learned a long time ago on the Windows version of regular (unpatched)
> POV-Ray to not run a long animation batch inside POV-Ray because it doesn't
> release the memory it allocates before starting another frame. Instead, I
Even if that were to be true (but it is not) you would not notice this
so soon on OS X.
You would need a scene which uses a *huge* amount of memory.
If you want to verify this you can run top in the terminal and watch
memory consumption for MegaPOV.
> run POV-Ray from the command line and feed it one frame at a time, thereby
> ensuring that POV-Ray releases any allocated memory as it exits after
> rendering each frame (my model uses a *lot* of texture, image and bump maps
> and consumes 500+ MB of memory to render 1 frame). But since there is no
> command line in Macintosh, I don't see any other alternative than to run
> animation jobs inside MacMegaPOV.
Command line on a Mac..... Are you serious ? ;-) :-)
If you wait for MegaPOV 1.1 you will be able to compile such a version
without any problems.
There are indeed quite a few people interested for such a version.
> Any suggestions??
More info? First thing to know is if this happens with a simple scene as
well.
That is always the first step.
Yvo
--
MacMegaPOV at:
http://users.skynet.be/smellenbergh
E-mail: yvo### [at] gmxnet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Scott Gammans <dee### [at] yahoocom> wrote:
[...]
> I am trying to run a rather long animation job (750 frames) on my G5
> workstation (OS X 10.2.7, *not* Panther) using MacMegaPOV Carbon 1.0, and
> without fail the job poops out after rendering 63 frames. I have the start
> and end frames set to 638 and 1388 respectively, but after 63 frames
> MacMegaPOV crashes and dies.
Your animation counts 750 frames but you start with frame 638 and end
with 1388?
Please what have you entered in 'Initial Frame', 'Final Frame', 'Subset
Start' and 'Subset end' on the clock panel of the prefrences dialog?
Yvo
--
MacMegaPOV at:
http://users.skynet.be/smellenbergh
E-mail: yvo### [at] gmxnet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Please what have you entered in 'Initial Frame', 'Final Frame', 'Subset
> Start' and 'Subset end' on the clock panel of the prefrences dialog?
638
1388
638
1388
"Yvo Smellenbergh" <yvo### [at] gmxnet> wrote in message
news:1g3npev.ecvzfx1qaqy2aN%yvos.s@gmx.net...
> Scott Gammans <dee### [at] yahoocom> wrote:
>
> [...]
>
> > I am trying to run a rather long animation job (750 frames) on my G5
> > workstation (OS X 10.2.7, *not* Panther) using MacMegaPOV Carbon 1.0,
and
> > without fail the job poops out after rendering 63 frames. I have the
start
> > and end frames set to 638 and 1388 respectively, but after 63 frames
> > MacMegaPOV crashes and dies.
> Your animation counts 750 frames but you start with frame 638 and end
> with 1388?
> Please what have you entered in 'Initial Frame', 'Final Frame', 'Subset
> Start' and 'Subset end' on the clock panel of the prefrences dialog?
>
> Yvo
>
> --
> MacMegaPOV at:
> http://users.skynet.be/smellenbergh
>
> E-mail: yvo### [at] gmxnet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
*sigh* No, Thorsten, I do care what you have to say--but let's not get into
another argument about your manner of online writing.
I may be wrong about what is causing the problem, but POV-Ray for Windows
*does* have some sort of memory allocation problem that, after a few dozen
frames, causes it to stop rendering with a memory allocation error because
it can't allocate any more memory to open one of the TGA bump map files in
my scene. I know it's not the most accurate measurement tool, but the
Windows XP Task Manager clearly shows POV-Ray consuming more and more memory
as each frame is rendered, until all physical memory is consumed and it
starts thrashing the virtual memory. When that also runs out, POV-Ray stops.
So it's either POV-Ray not releasing allocated memory after a frame is
completed, or it's a memory leak, or a problem with the way Windows XP
allocates memory to programs, or a little of all the above. And with a scene
file that takes nearly 600 MB of memory to render for one frame, it doesn't
take long for my workstation to grind to a halt when running a long
animation sequence totally from within POV-Ray.
To get around this problem--WHATEVER the reason for it--I figured out a long
time ago that if I execute POV-Ray from a batch file and render one frame at
a time from the command line, e.g....
pvengine +Iscene.pov +H384 +W512 +Q9 +KFI638 +KFF638 +Oscene_.png -D /NR
/EXIT
pvengine +Iscene.pov +H384 +W512 +Q9 +KFI639 +KFF639 +Oscene_.png -D /NR
/EXIT
pvengine +Iscene.pov +H384 +W512 +Q9 +KFI640 +KFF640 +Oscene_.png -D /NR
/EXIT
...POV-Ray always behaves perfectly and never is unable to parse a scene
file because it can't allocate the memory. The key is telling POV-Ray to
/EXIT after rendering one frame--that seems to force it to release any
memory it allocated back to Windows.
You will never be able to convince me that there is no problem with
long-running, memory-intensive animation jobs in POV-Ray, Thorsten, because
I've seen it happen.
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3fa14a7b@news.povray.org...
> In article <3fa141f5$1@news.povray.org> , "Scott Gammans"
> <dee### [at] yahoocom> wrote:
>
> > I learned a long time ago on the Windows version of regular (unpatched)
> > POV-Ray to not run a long animation batch inside POV-Ray because it
doesn't
> > release the memory it allocates before starting another frame.
>
> This simply is incorrect, but I know you don't care that I tell you.
Still,
> incorrect information posted tends to stick in new users' minds longer
than
> correct information, so if nobody says it isn't so they will take it as
> true...
>
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
By the way, my newsreader inserted carriage return/line feeds in my example
command line script below where I didn't want them... the script looks sorta
like this:
pvengine +Iscene.pov +H384 ... +KFI638 +KFF638 +Oscene_.png -D /NR /EXIT
pvengine +Iscene.pov +H384 ... +KFI639 +KFF639 +Oscene_.png -D /NR /EXIT
pvengine +Iscene.pov +H384 ... +KFI640 +KFF640 +Oscene_.png -D /NR /EXIT
"Scott Gammans" <dee### [at] yahoocom> wrote in message
news:3fa168a4$1@news.povray.org...
> *sigh* No, Thorsten, I do care what you have to say--but let's not get
into
> another argument about your manner of online writing.
>
> I may be wrong about what is causing the problem, but POV-Ray for Windows
> *does* have some sort of memory allocation problem that, after a few dozen
> frames, causes it to stop rendering with a memory allocation error because
> it can't allocate any more memory to open one of the TGA bump map files in
> my scene. I know it's not the most accurate measurement tool, but the
> Windows XP Task Manager clearly shows POV-Ray consuming more and more
memory
> as each frame is rendered, until all physical memory is consumed and it
> starts thrashing the virtual memory. When that also runs out, POV-Ray
stops.
> So it's either POV-Ray not releasing allocated memory after a frame is
> completed, or it's a memory leak, or a problem with the way Windows XP
> allocates memory to programs, or a little of all the above. And with a
scene
> file that takes nearly 600 MB of memory to render for one frame, it
doesn't
> take long for my workstation to grind to a halt when running a long
> animation sequence totally from within POV-Ray.
>
> To get around this problem--WHATEVER the reason for it--I figured out a
long
> time ago that if I execute POV-Ray from a batch file and render one frame
at
> a time from the command line, e.g....
>
> pvengine +Iscene.pov +H384 +W512 +Q9 +KFI638 +KFF638 +Oscene_.png -D /NR
> /EXIT
> pvengine +Iscene.pov +H384 +W512 +Q9 +KFI639 +KFF639 +Oscene_.png -D /NR
> /EXIT
> pvengine +Iscene.pov +H384 +W512 +Q9 +KFI640 +KFF640 +Oscene_.png -D /NR
> /EXIT
>
> ...POV-Ray always behaves perfectly and never is unable to parse a scene
> file because it can't allocate the memory. The key is telling POV-Ray to
> /EXIT after rendering one frame--that seems to force it to release any
> memory it allocated back to Windows.
>
> You will never be able to convince me that there is no problem with
> long-running, memory-intensive animation jobs in POV-Ray, Thorsten,
because
> I've seen it happen.
>
> "Thorsten Froehlich" <tho### [at] trfde> wrote in message
> news:3fa14a7b@news.povray.org...
> > In article <3fa141f5$1@news.povray.org> , "Scott Gammans"
> > <dee### [at] yahoocom> wrote:
> >
> > > I learned a long time ago on the Windows version of regular
(unpatched)
> > > POV-Ray to not run a long animation batch inside POV-Ray because it
> doesn't
> > > release the memory it allocates before starting another frame.
> >
> > This simply is incorrect, but I know you don't care that I tell you.
> Still,
> > incorrect information posted tends to stick in new users' minds longer
> than
> > correct information, so if nobody says it isn't so they will take it as
> > true...
> >
> > 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, it's any 63 frames of the same basic scene file, and with the exception
of Finder and whatever services are started when OS X boots up, I'm not
running any other processes.
I'm not using any MegaPOV features at all; the only reason I'm using
MacMegaPOV is the unavailability of POV-Ray for Macintosh on OS X 10.2.x.
This is a straight, standard POV-Ray *.POV file that includes seven *.INC
files and loads about 45 MB of *.PNG and *.TGA image, bump and texture map
files. Total memory used for each frame is about 550 MB.
thanks...
"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:s0u### [at] tritonimagicode...
> Scott Gammans wrote:
> > I'm not sure if this is a POV-Ray/Macintosh or MacMegaPOV problem, so
I'll
> > try here first.
> >
> > I am trying to run a rather long animation job (750 frames) on my G5
> > workstation (OS X 10.2.7, *not* Panther) using MacMegaPOV Carbon 1.0,
and
> > without fail the job poops out after rendering 63 frames. I have the
start
> > and end frames set to 638 and 1388 respectively, but after 63 frames
> > MacMegaPOV crashes and dies.
>
> Does it crash always after 63 frames even if you render a different
> subset or even identical frames? Try removing all uses of MegaPOV
> features and render with official POV.
>
> 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 <3fa168a4$1@news.povray.org> , "Scott Gammans"
<dee### [at] yahoocom> wrote:
> I may be wrong about what is causing the problem, but POV-Ray for Windows
> *does* have some sort of memory allocation problem that, after a few dozen
> frames, causes it to stop rendering with a memory allocation error because
> it can't allocate any more memory to open one of the TGA bump map files in
> my scene.
I guess you can also explain why these groups aren't full of people
complaining about it then. It is not like there aren't enough people using
the animation loop in POV-Ray, i.e. for the irtc...
> You will never be able to convince me that there is no problem with
> long-running, memory-intensive animation jobs in POV-Ray, Thorsten, because
> I've seen it happen.
I don't need to convince you. I know there is no memory leak big enough
that it could cause what you claim it would - for your claim to be correct
POV-Ray would have to forget about tens of megabytes of memory per frame!
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Scott Gammans wrote:
>
>
> I may be wrong about what is causing the problem, but POV-Ray for Windows
> *does* have some sort of memory allocation problem that, after a few dozen
> frames, causes it to stop rendering with a memory allocation error because
> it can't allocate any more memory to open one of the TGA bump map files in
> my scene.
I've had POVRay crash on Windows because of memory problems when running
(long) animation renders.
I'm not sure the problem lies with POVRay though.
When working on a program that would continuously load images a similar
(perhaps the same) problem occurred. I checked my code hundreds of times
but couldn't find any error, then tried to eliminate all non related
routines until finally I was left with a program that would only load an
image file. When running for a long time it would slowly eat away
Windows memory as was show with the resource monitor (or whatever it's
called).
There was nothing in my program I could change to avoid that (well, I
found a solution, but that's not relevant here).
So there may indeed be a memory leak occurring when you render
animations with POVRay that need to load a lot of images. The solution
would probably be not to reload image maps for each scene but to keep
them in memory.
Just my 2.5 cents.
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Remco de Korte wrote:
>When working on a program that would continuously load images a similar
>(perhaps the same) problem occurred. I checked my code hundreds of times
>but couldn't find any error, then tried to eliminate all non related
>routines until finally I was left with a program that would only load an
>image file. When running for a long time it would slowly eat away
>Windows memory as was show with the resource monitor (or whatever it's
>called).
>There was nothing in my program I could change to avoid that (well, I
>found a solution, but that's not relevant here).
>
>So there may indeed be a memory leak occurring when you render
>animations with POVRay that need to load a lot of images.
Yes, that is exactly, EXACTLY the behavior I have seen in the past.
>The solution
>would probably be not to reload image maps for each scene but to keep
>them in memory.
Would you mind explaining what you mean by that? Is this a suggestion for
the POV-Ray developers for the next version of POV-Ray, or are you
suggestion a technique that I can implement using the SDL? And if it's the
latter, please provide a brief SDL example of what you are talking about.
Many thanks...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK, I am seeing the same pattern of behavior on MacMegaPOV that I've
observed on long-running Windows POV-Ray animation renders.
I started another animation series at frame 942 at 5:30 PM yesterday
afternoon, and the OS X System Activity monitor showed MacMegaPOV consuming
just under 600 MB of memory, which was about right for the scene file I'm
rendering. But at 11:42 PM on frame 971 (30 frames into the job), the
amount of memory being used by MacMegaPOV had *tripled* to 1.5 GB. And at
5:30 AM on frame 1000 (59 frames along), the memory in use by MacMegaPOV is
a whopping 2.05 GB, with nearly all of the physical memory on my
workstation (2.5 GB) in use.
At the current rate of frame completion, MMP should get to frame 1004 (the
63rd frame in this series) in about 40 minutes. I wonder if the program
stops
because it runs out of physical memory, which at the current rate of memory
leakage will almost certainly occur by that 63rd frame? I'll post a message
to let everyone know what happens (unlike the last time, this time I have
all output streams being directed to a file, so hopefully when MMP aborts
I'll have something tangible I can show you).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, it must know I'm watching it like a hawk, because now it refuses to do
*anything* while it's parsing frame 1004. The System Activity monitor shows
that CPU activity is nil, memory consumption is 2.05 GB, and it's been
parsing the same scene file for 14 minutes now (just parsing, no
rendering). I ran a sample of what the program is doing (OS X has all kinds
of neat little goodies for checking on what a program is up to!) and I
copied below what was reported back. It looks like MMP is hung on something
called a "semaphore_wait_signal_trap". I'm just gonna kill it and restart
the sequence at frame 1004... don't have time to wait around for the
program to do something interesting, like actually *render* something (or
crash).
===============
2003-10-31 06:27:06.959 sample[702] Couldn't start c++filt for C++ name
demangling
Analysis of sampling pid 517 every 10.000000 milliseconds
Call graph:
228 Thread_0e0b
228 0x40e440
228 0x50e57c
228 0x50e32c
228 0x514da8
228 0x514a98
228 0x514a04
228 0x50edc0
228 0x4becc4
228 0x52c08c
228 0x50ed38
228 0x50edc0
228 0x4157e0
228 0x4107f0
228 0x512b7c
228 0x4bbce8
228 0x410860
228 0x5091c4
228 AESend
228 aeSend
228 AESendMessage
228
_Z10sendToSelfPK6AEDescPS_ll
228
_Z20aeDispatchAppleEventPK6AEDescPS_mPh
228 0x502ed4
228 0x5041d0
228 0x5056c0
228 0x40f030
228 0x4140ec
228 0x636c98
228 0x6368c8
228 0x635fac
228
0x611cb4
228
0x6088a4
228
0x608eac
228
0x60ede0
228 0x608fa0
228 0x608eac
228 0x60ede0
228 0x608b5c
228 0x659694
228 0x657874
228 0x605db0
228 0x6053a4
228 0x6182dc
228 0x61a6fc
228 0x5d7fe4
228 0x6180a0
228 0x61ac04
228 0x619570
228 0x61b15c
228 0x61ba54
228 0x6278dc
228 0x62fa8c
228 0x604150
228 0x661e48
228 0x658114
228 0x478798
228 0x40bf94
228 0x4ce530
228 0x4ca2f0
228 0x52b018
228 SizeWindow
228
_Z24MoveResizeWindowInternalP10WindowDatasssshhhhPK4Rectm
228
_ZN10WindowData14MoveResizeRgnsEssssb
228
_Z22CalculateWindowRegionsP10WindowDatab
228
ResetPlatformWindowShape
228
SetPlatformWindowShape
228
CGSSetWindowShapeWithWeighting
228
CGSRWLockLockForWriting
228
_pthread_cond_wait
228
semaphore_wait_signal_trap
228
semaphore_wait_signal_trap
Total number in stack (recursive counted multiple, when >=5):
Sort by top of stack, same collapsed (when >= 5):
semaphore_wait_signal_trap 228
Sample analysis of process 517 written to file /dev/stdout
Sampling process 517 each 10 msecs 300 times
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Scott Gammans wrote:
>
> >So there may indeed be a memory leak occurring when you render
> >animations with POVRay that need to load a lot of images.
>
> Yes, that is exactly, EXACTLY the behavior I have seen in the past.
>
> >The solution
> >would probably be not to reload image maps for each scene but to keep
> >them in memory.
>
> Would you mind explaining what you mean by that? Is this a suggestion for
> the POV-Ray developers for the next version of POV-Ray, or are you
> suggestion a technique that I can implement using the SDL? And if it's the
> latter, please provide a brief SDL example of what you are talking about.
>
> Many thanks...
It's a solution I used in the program I mentioned. It had to load
graphics data continuously and the only way I could solve it is to load
everything only one time and then keep it in memory.
For a POVRay animation render that would mean that it would keep
imagemaps and such in memory until the end of the render instead of
loading them for each frame, but to be honest I don't know how POVRay
handles things now, I'm only assuming it doesn't do this already.
So, obviously, this is not a solution you can achieve with the SDL. It
may only help to know that cutting down on the image loading *might*
help.
What puzzles me is how this could occur on Mac as well though...
When I ran into this problem and found that the cause wasn't in my own
code (eliminating almost all of it didn't solve it) I figured that it
was something in the way Windows (98 at the time) handles files.
Now I think that it could also have been somewhere in between (the code
that loads and decodes the images); I realize this seems vague, but I
didn't get any further then that... :)
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, I am convinced that MacMegaPOV has the same memory leak (or
**whatever** you want to call it, Thorsten!) that plagues the Windows
version when it comes to loading and unloading lots of large image maps
over a series of animation passes. The exact same problem happened
**AGAIN** with yet another animation job... the only difference this time
around was that I started rendering at frame 1055 and it froze after
completing frame 1117--the dreaded 63rd frame.
I'm in the middle of trying to get a project finished, but when I have some
free time I'm going to upload the files to the binaries section to prove
that what I'm seeing isn't just some figment of my imagination. Who
knows--maybe I'm doing something in the SDL that is causing WinPOV and
MacMegaPOV to slowly leak memory, and I'd be perfectly happy for Thorsten
to point out the foolish error of my ways so I can continue using
MacMegaPOV on my G5. As things stand now, though, I can't reliably use
software that buggers itself after a few dozen invocations.
Remco de Korte wrote:
>Scott Gammans wrote:
>>
>> >So there may indeed be a memory leak occurring when you render
>> >animations with POVRay that need to load a lot of images.
>>
>> Yes, that is exactly, EXACTLY the behavior I have seen in the past.
>>
>> >The solution
>> >would probably be not to reload image maps for each scene but to keep
>> >them in memory.
>>
>> Would you mind explaining what you mean by that? Is this a suggestion for
>> the POV-Ray developers for the next version of POV-Ray, or are you
>> suggestion a technique that I can implement using the SDL? And if it's the
>> latter, please provide a brief SDL example of what you are talking about.
>>
>> Many thanks...
>
>It's a solution I used in the program I mentioned. It had to load
>graphics data continuously and the only way I could solve it is to load
>everything only one time and then keep it in memory.
>For a POVRay animation render that would mean that it would keep
>imagemaps and such in memory until the end of the render instead of
>loading them for each frame, but to be honest I don't know how POVRay
>handles things now, I'm only assuming it doesn't do this already.
>
>So, obviously, this is not a solution you can achieve with the SDL. It
>may only help to know that cutting down on the image loading *might*
>help.
>
>What puzzles me is how this could occur on Mac as well though...
>When I ran into this problem and found that the cause wasn't in my own
>code (eliminating almost all of it didn't solve it) I figured that it
>was something in the way Windows (98 at the time) handles files.
>Now I think that it could also have been somewhere in between (the code
>that loads and decodes the images); I realize this seems vague, but I
>didn't get any further then that... :)
>
>Remco
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3fa3b203944a788685aba4bf0@news.povray.org> , "Scott Gammans"
<deepgloathatesspamaatyahoodotcom> wrote:
> Well, I am convinced that MacMegaPOV has the same memory leak (or
> **whatever** you want to call it, Thorsten!)
As POV-Ray is able to track all memory used, and that tracking will show all
memory "Lost" and then free it anyway, there is no memory leak. It is that
simple. Just repeating something that sin't a fact does not make it a
fact...
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 <web.3fa3b203944a788685aba4bf0@news.povray.org> , "Scott Gammans"
<deepgloathatesspamaatyahoodotcom> wrote:
> The exact same problem happened
> **AGAIN** with yet another animation job... the only difference this time
> around was that I started rendering at frame 1055 and it froze after
> completing frame 1117--the dreaded 63rd frame.
If you are so sure it ahppens with all animations, why don't you post a
scene that "shows" the problem in scene file binary group? Please remember
to include the INI file used to render it as well!
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> a écrit dans le message de
news:3fa3ca69@news.povray.org...
> If you are so sure it ahppens with all animations, why don't you post a
> scene that "shows" the problem in scene file binary group? Please
remember
> to include the INI file used to render it as well!
For the record, I think there may be something fishy with the loading of
large image maps. I had a problem recently (official POV, Windows XP) with
one JPEG (9000*4500): the scene rendered OK a few times and then BLAM!,
POV-Ray returned a message saying that it couldn't load the image due to
(IIRC, didn't write it down) a pointer problem. After closing and reloading
POV-Ray, the scene ran fine again. It happened several times, but as it was
a 4000-line scene that took several minutes to parse and used 1Gb or RAM,
bug hunting wasn't exactly easy. I didn't use the map eventually and the
problem never resurfaced. I've tried to replicate it with a simpler scene
including the map, at least to write down the error message, but everything
was OK (no unusual memory consumption in successive runs).
I've also seen POV-Ray suddenly complaining about a missing image map
between 2 successful runs of the same (unchanged) script. Again, this was
impossible to replicate.
G.
--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> As POV-Ray is able to track all memory used, and that tracking will show all
> memory "Lost" and then free it anyway, there is no memory leak. It is that
> simple. Just repeating something that sin't a fact does not make it a
> fact...
>
How about third-party libraries, e.g. TIFF library? Are they tested
against memory leaks (or perhaps they are used 'incorrectly', so memory
is not freed finally)? They don't use POV-Ray memory allocation routines
and as it seems from description, problem is related to image maps. So
even if POV-Ray code itself does not leak, POV-Ray as whole might have
memory leaks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vahur Krouverk wrote:
> Thorsten Froehlich wrote:
>
>> As POV-Ray is able to track all memory used, and that tracking will
>> show all
>> memory "Lost" and then free it anyway, there is no memory leak. It is
>> that
>> simple. Just repeating something that sin't a fact does not make it a
>> fact...
>>
> How about third-party libraries, e.g. TIFF library? Are they tested
> against memory leaks (or perhaps they are used 'incorrectly', so memory
> is not freed finally)? They don't use POV-Ray memory allocation routines
> and as it seems from description, problem is related to image maps. So
> even if POV-Ray code itself does not leak, POV-Ray as whole might have
> memory leaks.
There is of course an easy way to check that - use ppm/pgm for all
images. These don't use external libraries.
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 <8ji### [at] tritonimagicode> , Christoph Hormann
<chr### [at] gmxde> wrote:
> There is of course an easy way to check that - use ppm/pgm for all
> images. These don't use external libraries.
Neither does TGA.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> In article <web.3fa3b203944a788685aba4bf0@news.povray.org> , "Scott Gammans"
> <deepgloathatesspamaatyahoodotcom> wrote:
>
> > Well, I am convinced that MacMegaPOV has the same memory leak (or
> > **whatever** you want to call it, Thorsten!)
>
> As POV-Ray is able to track all memory used, and that tracking will show all
> memory "Lost" and then free it anyway, there is no memory leak. It is that
> simple. Just repeating something that sin't a fact does not make it a
> fact...
>
> Thorsten
>
I agree, but evidently there is a problem somewhere. It isn't
necessarily a bug in POVRay but it is something that occurs while
rendering animations in POVRay as well as in other situations.
Saying it isn't a memory leak, true as it is, doesn't really solve the
problem. Even though the actual 'bug' (if any) isn't in POVRay it would
be nice to know how to avoid such things, either in the scene or ini
file or in the way you render things (my suggestion for Scott would be
to render it in chunks of 63 frames ;)) or maybe even in a line in the
program code somewhere.
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote
>> I know there is no memory leak big
>> enough that it could cause what you claim
>> it would - for your claim to be correct
>> POV-Ray would have to forget about tens
>> of megabytes of memory per frame!
>> As POV-Ray is able to track all memory
>> used, and that tracking will show all
>> memory "Lost" and then free it anyway,
>> there is no memory leak.
I am *so* going to enjoy watching you eat your words, you arrogant
smarty-pants.
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 +FN +UA +KFI0001 +KFF1800
The output should be a series of 1,800 PNG 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.
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. Incidentally, the same
thing happens if you repeat this test by generating a PNG file in step one
and using that output file for the texture map in step two... with the PNG
map it took 6 minutes and 39 seconds for the parse error to occur at frame
461.
As you can see, this demonstration of the memory bug was generated
completely from within POV-Ray without the use of any external image
processing programs or any other external processing. Since Thorsten has
already stated that POV-Ray does not use any external libraries for Targa
files, it follows that there must be a memory allocation problem somewhere
within POV-Ray itself.
// 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I am *so* going to enjoy watching you eat your words, you arrogant
> smarty-pants.
I'm not sure whether Thorsten should ever reply to this...
> As you can see, this demonstration of the memory bug was generated
> completely from within POV-Ray without the use of any external image
> processing programs or any other external processing. Since Thorsten has
> already stated that POV-Ray does not use any external libraries for Targa
> files, it follows that there must be a memory allocation problem somewhere
> within POV-Ray itself.
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 should try again by saving TGA or PPM frames, not PNG. Then please
report your corrected results so that someone can start analyzing
what's going on. I will try your scripts myself (on Linux, but that
does not matter if there is a memory leak in povray) in the light of
the rendering your animation as TGA frames.
BTW, nobody said not to use an external image processing program.
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] yahoocom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Scott Gammans" <dee### [at] yahoocom> a écrit dans le
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Tran" <tra### [at] inapginrafr> a écrit dans le message de
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <new### [at] deletethispovrayorg> a écrit dans le message de
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] trfde>
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...
> "Scott Gammans" <dee### [at] yahoocom> a écrit dans le
> 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
|
|
| |
| |
|
|
|
|
| |
