 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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] gmx net> 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
|
|
| |
| |
|
|
|
|
| |
|
|
