|
![](/i/fill.gif) |
Skywise nous apporta ses lumieres en ce 06/06/2006 15:28:
> "Chris B" <c_b### [at] btconnect com nospam> 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
|
![](/i/fill.gif) |