I am running POV 3.6.1 using Windows 98SE, on a Pentium II with 512 MB ram,
and a 2 GB hard drive.  Whenever I render a rather complex scene (for
example, using a #while loop to create and/or place thousands of objects,
each with a random color), the parsing and rendering naturally takes a
rather long time...with a fair amount of hard-drive activity.  That's to be
expected, I guess. But when I STOP the render before it's complete, the
computer still keeps "churning away" (with the hard drive still as active
as before), sometimes for 10 minutes or more, depending on the scene,
before finally stopping and returning control to the POV editor. It "seems"
as if the computer is continuing to process the scene, even after the STOP
command is issued. Are there other POV users out there with this problem?
Does anyone know WHY this is happening? It would be nice if STOP RENDER
actually stopped the
entire process instantly... the way most other programs work.  Is this a
built-in problem with Windows and its hard-drive operating system?  Or is
it something odd about the way POV works with Windows?

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> Does anyone know WHY this is happening? It would be nice if STOP RENDER
> actually stopped the
> entire process instantly... the way most other programs work.

  Most other programs don't allocate millions of tiny chunks of memory
which they have to then free when they stop doing whatever they were
doing.

  A solution to this would require a complete redesign of how povray
allocates and deallocates memory. Not a trivial task.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > Does anyone know WHY this is happening? It would be nice if STOP RENDER
> > actually stopped the
> > entire process instantly... the way most other programs work.
>
>   Most other programs don't allocate millions of tiny chunks of memory
> which they have to then free when they stop doing whatever they were
> doing.
>
>   A solution to this would require a complete redesign of how povray
> allocates and deallocates memory. Not a trivial task.
>
> --
>                                                           - Warp

Very interesting!  (My second guess as to this phenomenon was that the
computer was having to "retrieve" or "clean out" memory it had used...which
you've corroborated.) I'm happy (??) to know that it's not something to do
with my own computer setup. Thanks for the info!

Post a reply to this message

Kenneth wrote:
> 
> Very interesting!  (My second guess as to this phenomenon was that the
> computer was having to "retrieve" or "clean out" memory it had used...which
> you've corroborated.) I'm happy (??) to know that it's not something to do
> with my own computer setup. Thanks for the info!

Actually that's not quite right.  It would not take that long to stop a 
render it you'd stop it by terminating the POV-Ray process.  You can 
check this by killing POV-Ray in the task manager - i assume it will 
usually not take long to do so.

This is one of the advantages of using the command line version - you 
don't have any problem cancelling a render.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> Very interesting!  (My second guess as to this phenomenon was that the
> computer was having to "retrieve" or "clean out" memory it had used...which
> you've corroborated.) I'm happy (??) to know that it's not something to do
> with my own computer setup. Thanks for the info!

  OTOH your situation is rather unusual, still. I personally almost never
have had such problems even with larger scenes.
  How large is your scene exactly? How many objects?

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > Very interesting!  (My second guess as to this phenomenon was that the
> > computer was having to "retrieve" or "clean out" memory it had used...which
> > you've corroborated.) I'm happy (??) to know that it's not something to do
> > with my own computer setup. Thanks for the info!
>
>   OTOH your situation is rather unusual, still. I personally almost never
> have had such problems even with larger scenes.
>   How large is your scene exactly? How many objects?
>
> --
>                                                           - Warp

A common example (for me) would be this:
1) Create a rather simple object in sPatch
2) Export to POV as an .inc file, containing a union of
Bicubic_patches...REDUCING the u_steps and v_steps from the default 3 down
to 1, so as to cut down on the number of triangles POV has to deal with.
3) #declare the object in my POV scene (only once), adding scaling and a
basic grey-scale 8-bit image map.
4) Place 40,000 of these objects randomly, using a trace operation inside a
#while loop, applying an extra semi-transparent random color overlay to
each one.

The render size is usually 720 X  540, at AA  0.1

I do realize that the semi-transparent textures are VASTLY increasing the
parsing and/or rendering times (and account for a lot of hard disk
activity.)

Any comments or suggestions?

Post a reply to this message

For those interested, I've come across another news thread that relates to
this question...
<42e7e533$1@news.povray.org>

Ken

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> Kenneth wrote:
> >
> > Very interesting!  (My second guess as to this phenomenon was that the
> > computer was having to "retrieve" or "clean out" memory it had used...which
> > you've corroborated.) I'm happy (??) to know that it's not something to do
> > with my own computer setup. Thanks for the info!
>
> Actually that's not quite right.  It would not take that long to stop a
> render it you'd stop it by terminating the POV-Ray process.  You can
> check this by killing POV-Ray in the task manager - i assume it will
> usually not take long to do so.
>
> This is one of the advantages of using the command line version - you
> don't have any problem cancelling a render.
>
> Christoph
>

Thanks, Christoph, that works!!  Instead of 10 minutes, it now takes less
than 10 seconds.  Not bad!!  And without crashing the computer.  : )

I'm somewhat embarassed to admit that I've never used (or had to use?) the
TaskManager app.  So thanks for that tip in and of itself.

Stopping a render like this does raise a question in my mind, though: If
POV-Ray normally takes time to "clean out" (or "make available again"?) the
many small fragments of hard drive memory it has used, am I creating
"other" problems by terminating POV this way? So far, it doesn't seem
so...but I'm not Windows-saavy enough to know.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
>
> Stopping a render like this does raise a question in my mind, though: If
> POV-Ray normally takes time to "clean out" (or "make available again"?) the
> many small fragments of hard drive memory it has used, am I creating
> "other" problems by terminating POV this way? So far, it doesn't seem
> so...but I'm not Windows-saavy enough to know.

I believe you very well could be causing other problems.  POV fills
available RAM, and then starts writing to the "swap file" on the hard disk.
 I have had these long shut-down times happen to me, on a new Athlon system
with a gig of RAM, usually when I am using photon mapping.  Sometimes
Windows will even increase the size of my swap file on the fly.  I would
assume that POV tries to be "tidy" and clean up the swap file before
exiting.  If not allowed to do so, will all that data just stay there
hogging disk space and slowing the system? I am not sure, but even on my
roomy 1600 gig drive I'd rather not take the chance.

Post a reply to this message

Kenneth wrote:
> 
> Thanks, Christoph, that works!!  Instead of 10 minutes, it now takes less
> than 10 seconds.  Not bad!!  And without crashing the computer.  : )

Just to make this clear - this was not intended as a suggestion for 
normal operation.  It was just meant to illustrate that the long time 
required to stop a render is not inevitable in general but only when you 
don't want to terminate the process at the same time.  There is no point 
in using the a GUI version of POV-Ray if you stop the render by killing 
the program.

> Stopping a render like this does raise a question in my mind, though: If
> POV-Ray normally takes time to "clean out" (or "make available again"?) the
> many small fragments of hard drive memory it has used, am I creating
> "other" problems by terminating POV this way? 

In any modern OS when a process is terminated - no matter which way - 
the allocated memory gets freed automatically (more precise: the address 
space of the process simply ceases to exist).

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message