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:32:58 EDT (-0400)
  Re: Screwy render times in a #switch in animation.  
From: gregjohn
Date: 1 Feb 2007 12:40:00
Message: <web.45c2251f26d2c6dd40d56c170@news.povray.org>
"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

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