I have experienced a problem with an extreme render slowdown and I just came
up with a workaround.

Consider:

//BEGIN SOME SDL-------------------
#switch (clock)
#range (-2/180,8/180)
  #include "LOGO_SCENE.pov"

  // LOGO_SCENE.pov is three lines of text object
  // and a proximity pattern.
  // Very few objects and fewer variables are called

#break

#range (8.0001/180,28/180)
    #include "CHARACTER_SCENE.pov"

  // "CHARACTER_SCENE.pov" has a few objects,
  // but boxes with layered patterned pigments,
  // a blob object with hundreds of components and
  // multi-layered deep object textures,
  // and maybe a thousand variable declarations.
#break
// END SOME SDL----

Now consider this rendering scheme:

SF  EF   TIME    WHAT IS IT
183 192   18 s   ten frames of "LOGO_SCENE.pov"
193 202    4 s   ten frames of "CHARACTER_SCENE.pov"

Comment: Neither scene takes long to render, if one renders them alone by
themselves.

Now consider what happens if your render session contains both (which would
happen if you let it render overnight):

SF  EF   TIME    WHAT IS IT
188 197   80 s   five frames of "LOGO_SCENE.pov", five of
"CHARACTER_SCENE.pov"

Comment: The character scene now takes 36X longer to render!!


Now consider making povray thinking about all of those variables and objects
in its first frame (Even if they don't appear on screen!!)


//BEGIN SOME SDL-------------------
#switch (clock)
#range (-2/180,8/180)
   #include "LOGO_SCENE.pov"

   // LOGO_SCENE.pov is three lines of text object
  // and a proximity pattern.
  // Very few objects and fewer variables are called

  #include "CHARACTER_SCENE.pov"
  // HEY, I added this!

#break

#range (8.0001/180,28/180)
    #include "CHARACTER_SCENE.pov"

  // "CHARACTER_SCENE.pov" has a few objects,
  // but boxes with layered patterned pigments,
  // a blob object with hundreds of components and
  // multi-layered deep object textures,
  // and maybe a thousand variable declarations.
#break
// END SOME SDL----


SF  EF
188 197   13 s   five frames of "MODIFIED_logo_scene", five of
"character_scene"

Now there is no render slowdown!



DISCUSSION.
It is problematic to have to do this for proper design of an animation
sequence. Could it be that povray is deciding how much memory to allocate
for an
entire render session based solely on the complexity of the very first
frame?

I could imagine that either it's an oversight, or something impossible for
povray to do. I at least now know to #include the most complex scene file
in frame 1 of an animation.  Hope this note helps others.

Post a reply to this message

gregjohn wrote:
> Could it be that povray is deciding how much memory to allocate
> for an
> entire render session based solely on the complexity of the very first
> frame?

No, you are chasing ghosts here: You have insufficient memory, and with
memory fragmentation after the first render, you just run a bit above the
swapping threshold for the second one. Hence the big difference in speed.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> gregjohn wrote:
> > Could it be that povray is deciding how much memory to allocate
> > for an entire render session based solely on the complexity of
> > the very first frame?
>
> No, you are chasing ghosts here: You have insufficient memory, and with
> memory fragmentation after the first render, you just run a bit above the
> swapping threshold for the second one. Hence the big difference in speed.
>
>  Thorsten


If you are making an argument about straw that broke the camel's back, the
opposite is true-- adding more straw makes the camel run better.

I even added another two more complex include files to the first render:


TIME TO DO 10 FRAMES (5 SIMPLE then 5 COMPLEX)
PARSE RENDER TOTAL SCENE FILE

 1    87     88   original, first 5 frames very simple scene

 2    11     13   added one moderately complex and unseen scene to the first
5 frames.

51    10     61   added two more unseen includes to the first 5 frames, with
multiple blob characters + complex CSG in them.


Even when I make it parse much more, it still renders much more quickly.
Straw makes the camel faster!


So it is an unfortunate way in which povray handles memory or some other
resource. Now I could imagine it is impractical or impossible to have it go
back and get more "stuff" once it's started down the road. But it's not a
ghost. It's a serious problem that requires design-around in order for
povray to be practical for serious projects.

Post a reply to this message

I've suspected before that some things are being
fast disk loaded from memory, but I'm unsure if
pov is actually the memory manager for that.
It might be windows doing it behind the scenes.

Is the linux version the same way?

Post a reply to this message

"Tim Attwood" <tim### [at] comcastnet> wrote:
> I've suspected before that some things are being
> fast disk loaded from memory, but I'm unsure if
> pov is actually the memory manager for that.
> It might be windows doing it behind the scenes.
>
> Is the linux version the same way?


I put some files which demonstrate the bug (or my SDL poor construction) in
povray.text.scene-files.

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> wrote:
> "Tim Attwood" <tim### [at] comcastnet> wrote:
> > I've suspected before that some things are being
> > fast disk loaded from memory, but I'm unsure if
> > pov is actually the memory manager for that.
> > It might be windows doing it behind the scenes.
> >
> > Is the linux version the same way?
>
>
> I put some files which demonstrate the bug (or my SDL poor construction) in
> povray.text.scene-files.

I experienced the same problem a while back on one of my animations though
not as severe as yours.  Mine only slowed down by a factor of about five.
I took your scene and ran it on two machines.  The first is a 2.4Ghz
Pentium 4 with 512M running linux.  The other is an AMD X2 +5000 with 2G
running Windows Media Edition.  I tested both 3.6 and the latest 3.7 beta.
All times are in seconds.
To make it as simple as possible I only ran two frames, 10 and 11.

                      Linux-Pentium            Windows-AMD
Command               3.6       3.7           3.6       3.7

+kff20 +sf10 +ef10    <1        <1            0.39      0.69
+kff20 +sf11 +ef11    <1        <1            0.30      0.61
+kff20 +sf10 +ef11    48        1.19         25.63      1.20

On the 2 frame animation the first frame was less than 1 sec on both
machines.
I don't have any idea what caused the slowdown, but it seems to be resolved
in 3.7

Post a reply to this message

David E. LeMasters wrote:
>  I tested both 3.6 and the latest 3.7 beta.
> All times are in seconds.
> To make it as simple as possible I only ran two frames, 10 and 11.
> 
>                       Linux-Pentium            Windows-AMD
> Command               3.6       3.7           3.6       3.7
> 
> +kff20 +sf10 +ef10    <1        <1            0.39      0.69
> +kff20 +sf11 +ef11    <1        <1            0.30      0.61
> +kff20 +sf10 +ef11    48        1.19         25.63      1.20
> 
> On the 2 frame animation the first frame was less than 1 sec on both
> machines.
> I don't have any idea what caused the slowdown, but it seems to be
> resolved in 3.7


Wow that is most helpful. Hey, pov already fixed it! No ghost!

But for the short term I think I have to do the math for this one project,
as to whether the slowdown for other frames makes up for the speedup in the
speed bump between scenes.

Post a reply to this message

I played around with your code a bit more, pulling out things to try
and locate what is causing the problem.  This is what I came up with:

#if(clock<=0.5)
  box{0,1}
#else
  text{ ttf "COMICBD.ttf" "Caption1" 1,0 pigment{rgb 0}}
#end

When I run this on my linux box this is what I get:

+kff20 +sf1 +ef10      5 sec.
+kff20 +sf11 +ef20    23 sec.
+kff20 +sf1 +ef20    163 sec.

When I swap the box and text objects like this:

#if(clock<=0.5)
  text{ ttf "COMICBD.ttf" "Caption1" 1,0 pigment{rgb 0}}
#else
  box{0,1}
#end

I get this:

+kff20 +sf1 +ef10     22 sec.
+kff20 +sf11 +ef20     4 sec.
+kff20 +sf1 +ef20     27 sec.


When I try this:

#if(clock<=0.5)
  text{ ttf "COMICBD.ttf" "Caption1" 1,0 pigment{rgb 0}}
#else
  text{ ttf "COMICBD.ttf" "Caption2" 1,0 pigment{rgb 0}}
#end

The results are:

+kff20 +sf1 +ef10     22 sec.
+kff20 +sf11 +ef20    22 sec.
+kff20 +sf1 +ef20     44 sec.

So there is a problem with 3.6 in the first case.  This problem has been
resolved on the 3.7 beta, so I don't see where it would be worth the
developers time to pursue fixing it on 3.6.   But at least this might give
you an idea of how to structure your code to work around it.

Post a reply to this message

Amazing detective work, David!

Question to Thorsten, et al:

When it comes to fonts, I'm willing to throw any aspect of what I'm doing on
the trash heap.  What are the optimum font file fomats for povray?  Could I
be using a buggy font?




"David E. LeMasters" <dle### [at] comcastnet> wrote:
> I played around with your code a bit more, pulling out things to try
> and locate what is causing the problem.  This is what I came up with:
>
> #if(clock<=0.5)
>   box{0,1}
> #else
>   text{ ttf "COMICBD.ttf" "Caption1" 1,0 pigment{rgb 0}}
> #end
>
> When I run this on my linux box this is what I get:
>
> +kff20 +sf1 +ef10      5 sec.
> +kff20 +sf11 +ef20    23 sec.
> +kff20 +sf1 +ef20    163 sec.
>
> When I swap the box and text objects like this:
>
> #if(clock<=0.5)
>   text{ ttf "COMICBD.ttf" "Caption1" 1,0 pigment{rgb 0}}
> #else
>   box{0,1}
> #end
>
> I get this:
>
> +kff20 +sf1 +ef10     22 sec.
> +kff20 +sf11 +ef20     4 sec.
> +kff20 +sf1 +ef20     27 sec.
>
>
> When I try this:
>
> #if(clock<=0.5)
>   text{ ttf "COMICBD.ttf" "Caption1" 1,0 pigment{rgb 0}}
> #else
>   text{ ttf "COMICBD.ttf" "Caption2" 1,0 pigment{rgb 0}}
> #end
>
> The results are:
>
> +kff20 +sf1 +ef10     22 sec.
> +kff20 +sf11 +ef20    22 sec.
> +kff20 +sf1 +ef20     44 sec.
>
> So there is a problem with 3.6 in the first case.  This problem has been
> resolved on the 3.7 beta, so I don't see where it would be worth the
> developers time to pursue fixing it on 3.6.   But at least this might give
> you an idea of how to structure your code to work around it.

Post a reply to this message

gregjohn nous apporta ses lumieres en ce 06-02-2007 12:31:
> I have experienced a problem with an extreme render slowdown and I just came
> up with a workaround.

> Consider:

> //BEGIN SOME SDL-------------------
> #switch (clock)
> #range (-2/180,8/180)
>   #include "LOGO_SCENE.pov"

>   // LOGO_SCENE.pov is three lines of text object
>   // and a proximity pattern.
>   // Very few objects and fewer variables are called

> #break

> #range (8.0001/180,28/180)
>     #include "CHARACTER_SCENE.pov"

>   // "CHARACTER_SCENE.pov" has a few objects,
>   // but boxes with layered patterned pigments,
>   // a blob object with hundreds of components and
>   // multi-layered deep object textures,
>   // and maybe a thousand variable declarations.
> #break
> // END SOME SDL----

> Now consider this rendering scheme:

> SF  EF   TIME    WHAT IS IT
> 183 192   18 s   ten frames of "LOGO_SCENE.pov"
> 193 202    4 s   ten frames of "CHARACTER_SCENE.pov"

> Comment: Neither scene takes long to render, if one renders them alone by
> themselves.

> Now consider what happens if your render session contains both (which would
> happen if you let it render overnight):

> SF  EF   TIME    WHAT IS IT
> 188 197   80 s   five frames of "LOGO_SCENE.pov", five of
> "CHARACTER_SCENE.pov"

> Comment: The character scene now takes 36X longer to render!!


> Now consider making povray thinking about all of those variables and objects
> in its first frame (Even if they don't appear on screen!!)


> //BEGIN SOME SDL-------------------
> #switch (clock)
> #range (-2/180,8/180)
>    #include "LOGO_SCENE.pov"

>    // LOGO_SCENE.pov is three lines of text object
>   // and a proximity pattern.
>   // Very few objects and fewer variables are called

>   #include "CHARACTER_SCENE.pov"
>   // HEY, I added this!

> #break

> #range (8.0001/180,28/180)
>     #include "CHARACTER_SCENE.pov"

>   // "CHARACTER_SCENE.pov" has a few objects,
>   // but boxes with layered patterned pigments,
>   // a blob object with hundreds of components and
>   // multi-layered deep object textures,
>   // and maybe a thousand variable declarations.
> #break
> // END SOME SDL----


> SF  EF
> 188 197   13 s   five frames of "MODIFIED_logo_scene", five of
> "character_scene"

> Now there is no render slowdown!



> DISCUSSION.
> It is problematic to have to do this for proper design of an animation
> sequence. Could it be that povray is deciding how much memory to allocate
> for an
> entire render session based solely on the complexity of the very first
> frame?

> I could imagine that either it's an oversight, or something impossible for
> povray to do. I at least now know to #include the most complex scene file
> in frame 1 of an animation.  Hope this note helps others.
How many objects in the first set of frames? Is it less than the bounding threshold?
If the answer the second question is YES, then there will be NO bounding at all 
for the entire animation.
A solution: add 1 or 2 dumy objects, like small sphere with no_image, no_shadow 
and no_reflection or objects placed off field: behind the camera or 
behind/inside some opaque object.
Others have been hit with that problem in animation with a growing number of 
objects: 0 to 2 objects in the first frame and eventualy 1000s in subsequent frames.

-- 
Alain
-------------------------------------------------
The tree of liberty must be refreshed from time to time with the blood of
patriots and tyrants.
Thomas Jefferson

Post a reply to this message