POV-Ray : Newsgroups : povray.newusers : #include, animations, : Re: #include, animations, Server Time
29 Jul 2024 06:19:38 EDT (-0400)
  Re: #include, animations,  
From: Skywise
Date: 6 Jun 2006 15:28:43
Message: <4485d76b@news.povray.org>
"Chris B" <c_b### [at] btconnectcomnospam> wrote in
news:448573e1$1@news.povray.org: 

<Snipola>
> Hi Brian,
> 
> I've not noticed any increase in time with rendering of successive
> frames in an of my animations. Indeed I generally do a quick calculation
> based on the time for first couple of frames to work out how long the
> whole thing will take and it generally works out fairly close to what
> I'd expect. I would think your best option would be to reduce the
> complexity and see whether the problem persists.
> 
> For example, you could try rendering the same frame 10 times and see
> whether each successive frame takes the same time or not. That is to
> say, hard code the include of frame 5 and see whether it takes the same
> amount of time for each of 10 frames in an animation.
> 
> If you can simplify it down, so that you end up with a small number of
> very short files that illustrate the problem, then you could post your
> SDL on the scene-files newsgroup and others could see if they can
> replicate your problem.
> 
> Regards,
> Chris B.

OK, I made my first ten includes all the same as #10. Everything ran
lickity-split like expected. So, I started reducing things and found
that it was a problem with the first include, which happened to be
blank.

Thinking it was just becuase it was blank, I added 1 sphere object.
I manually moved it off screen so the first frame can still be blank.
Nope, same problem. Things slowed down again.

I then thought it was because the rendered scene was blank, so I
put the 1 lone sphere object back in place so it could be seen. Still
slowed down.

So, I went back to duplicating the contents of #10 back into #1.
OK, we're back to it working fine. Time for a process of elimination.

I started chopping away at the number of objects in the first frame.
I get it down to three and things are ok. Any less and things crap
out. 0, 1, or 2 objects and it just freaks out.

OK, fine, I can live with that. I try moving the three objects out
of sight so the first frame can be blank like it's supposed to be.
Everything still works fine!

Seems like the issue is specific to the first include file. It must
have at least three objects in it.

I just let it run through my 365 frames and it completed in 9m 11s.
That's about 1.5 seconds per frame. That's a lot better than 7 seconds
per frame doing it with the render queue! Some of the frames have
well over 10,000 objects in them.

Another advantage of doing it this way is that it seems the render
queue has a limit to it's list size.

Brian
-- 
http://www.skywise711.com - Lasers, Seismology, Astronomy, Skepticism
Seismic FAQ: http://www.skywise711.com/SeismicFAQ/SeismicFAQ.html
Quake "predictions": http://www.skywise711.com/quakes/EQDB/index.html
Sed quis custodiet ipsos Custodes?


Post a reply to this message

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