GROUP O'FRAMES  RENDER TIME TOTAL FOR 160x120's
Frames 1-192:   70 secs [sic]
Frames 192-200  19 secs
Frames 190-200  14 min
Frames 199-200  6 secs
Frames 1-380    (>8 hr)

Frames 1 to 192 are a box with an image map (previous frames, already
rendered). It renders lightning fast.

Frame 193ff are an innocent-enough scene, nothing to choke a render when it
renders several frames by itself.

But when I do some of the box-frames first and then go to my scene, povray
takes three minutes a frame to render to do it!

Any ideas?


--------START OF CODE SNIPPET --------------
#declare clockeee=clock;
#include"duelcaptions11.pov"  // just a macro with my caption system

#switch (clockeee) 

#range (0/180,8/180)    
        #local
this_name=concat("/home/greg/images/charanim080",str(frame_number,-3,0) )

box{<0,0,0.75> <4,3,0.75> 
        pigment{image_map {png this_name map_type 0 once } scale<4/3,1,1>}
        finish{ambient rgb 1}
        translate<-0.65,-0.5,0>
        transform{cameratransform}
        }
#break 

#range (8.001/180,28/180)
        #include "chartest03.pov" // a scene with boxes & blobs
        captionmacro(14,18,clockeee,180, "caption","caption ","")//
        captionmacro(19,23,clockeee,180, "caption","caption","caption")//
        captionmacro(24,28,clockeee,180, "caption","caption ","caption")//
#break 

...etc...
-------------------------------

Post a reply to this message

I tried the same thing with povray 3.6.1c.icl8.win32 on a slower laptop,
yes, using windows.  Here the lumps of frames tell the story more
coherently, and I even switched what was happening in scene 1. Scene 1 now
has a fancy proximity pattern effect calculated for every frame.


Frames   CPU time,  what's rendered
183-188  9.58 s, 6 frames of scene 1
184-189  9.63 s, 6 frames of scene 1
185-190  9.61 s, 6 frames of scene 1
186-191  9.54 s, 6 frames of scene 1
187-192  9.56 s, 6 frames of scene 1
188-193  21.4 s, 5 of 1, 1 frame of scene 2
189-194  34.0 s, 4 of 1, 2 frames of scene 2
190-195  44.9 s, 3 of 1, 3 frames of scene 2
191-196  56.8 s, 2 of 1, 4 frames of scene 2
192-197  69.2 s, 1 of 1, 5 frames of scene 2
193-198  4.78 s, 6 frames of scene 2
194-199  4.88 s, 6 frames of scene 2
195-200  4.82 s, 6 frames of scene 2.


Thus, in an "animation render session," if it has more than one set of scene
files to parse, the render time is greatly slowed.  On a large animation
left overnight on a linux box, this effect was snowballing to make 3 minutes
of
render per frame! But stopping the render there and starting again leaves no
worries.

So any tips on how to avoid this problem?  Is there something wrong with
setting up alternate scenes in an animation with the #switch command?

Post a reply to this message

> So any tips on how to avoid this problem?  Is there something wrong with
> setting up alternate scenes in an animation with the #switch command?
I'm not 100% sure, but if some of your frames call a macro
that is #included once but called multiple times during a single frame, it
may be accessing that file multiple times... so pasting the macro
into the main file could speed things up.

Post a reply to this message

"Tim Attwood" <tim### [at] comcastnet> wrote:
> > So any tips on how to avoid this problem?  Is there something wrong with
> > setting up alternate scenes in an animation with the #switch command?
>
> I'm not 100% sure, but if some of your frames call a macro
> that is #included once but called multiple times during a single frame, it
> may be accessing that file multiple times... so pasting the macro
> into the main file could speed things up.


Consider:

#switch (clock)
#range(0,a-0.0001)
#include "File_for_scene_01.pov"
#break
#range (a,b-0.0001)
#include "File_for_scene_02.pov"
#break
#range (b,1)
#include "File_for_scene_03.pov"
#break
#end


Now, for animation rendering sessions of frames equivalent to these clock
values:
(0,a), there are no worries
(a,1), there are no worries.

But for any c and d, c<a<d :
(c,d) there is a 10-100x slowup in render speed per frame once the povray
animation routine hits clock>a.

This is surely the case of my specific and complicated
File_for_scene_0X.pov's.

Now the question is, Why?

If it were a bug in povray, you'd think others would complain.  Or I would
see it happen with the most simple File_for_scene_0X.pov.  I tried it with
a few spheres and saw no worries.

If it were something in my SDL that were poorly designed, what could it be?
And I'm actually doubtful here, too, as rendering it in two distinct chunks
shows no slowups.  Is there a better design for switching between frames?

Post a reply to this message

gregjohn wrote:
> Now the question is, Why?

Does POV-Ray actually release back to the OS any memory it has 
allocated? Perhaps you are paging/swapping due to large chunks of memory 
thru which data structures are suboptimally allocated? Check how much 
physical memory you're using when it's slow, and how much paging is 
going on?

-- 
   Darren New / San Diego, CA, USA (PST)
     You know it's time to trim your beard when your
     wife stops calling you Husband and starts calling
     you Husbollah.

Post a reply to this message

Or this one...

http://news.povray.org/povray.animations/thread/%3Cweb.43fce6995f972968fc5d75160@news.povray.org%3E/

Post a reply to this message

I don't know what happend to my first reply but it was a link to this
thread:
http://news.povray.org/povray.animations/thread/%3Cweb.45827829b0256beac77a5930@news.povray.org%3E/

"Charles C" <nomail@nomail> wrote:
> Or this one...
>
>
http://news.povray.org/povray.animations/thread/%3Cweb.43fce6995f972968fc5d75160@news.povray.org%3E/

Post a reply to this message