POV-Ray : Newsgroups : povray.general : Screwy render times in a #switch in animation. : Re: Screwy render times in a #switch in animation. Server Time
31 Jul 2024 14:28:03 EDT (-0400)
  Re: Screwy render times in a #switch in animation.  
From: gregjohn
Date: 31 Jan 2007 13:00:00
Message: <web.45c0d88f26d2c6dd40d56c170@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.