POV-Ray : Newsgroups : povray.newusers : #include, animations, : Re: #include, animations, Server Time
29 Jul 2024 06:22:56 EDT (-0400)
  Re: #include, animations,  
From: Alain
Date: 8 Jun 2006 17:07:38
Message: <4488919a@news.povray.org>
Skywise nous apporta ses lumieres en ce 06/06/2006 15:28:
> "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
Looks more like a bounding blocks problem. The default thresshold for bounding is 3.
If the first 
frame of an animation don't trigger bounding, it stays OFF for the whole anomation. If
I remember 
correctly, it was discused in another thread a while back.
The workaround was effectively to put 3 "dummy" objects out of view, like behind the
camera, under a 
ground plane or beyond a world sphere.
I don't think that any infinite object count, or even scene encompassing finite
objects like the 
world sphere or box.

-- 
Alain
-------------------------------------------------
Getting the job done is no excuse for not following the rules.


Post a reply to this message

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