Mike Williams wrote:
> 
> Wasn't it Andrel C. Linnenbank who wrote:
> >>
> >> >Second point is that I used a parameterization for the sizes
> >> >of the spheres that depended on the clock to generate an animation.
> >> >It was a rather complex formula. I now use a different method where
> >> >I generate an different include file for every frame. The reason
> >> >is that this seems to be much faster. Apparently the formula
> >> >is computed for every pixel in stead of ones per frame. I
> >> >think some caching may improve the speed of rendering.
> >>
> >> I can't reproduce that with simple formulae that use the clock.
> >> You're not using functions by any chance are you?
> >
> >I meant that I used things like
> >
> >sphere_sweep {
> > catmull_rom_spline
> > 11,
> > <-0.785398,0.000000,0.000000>,1-(exp(-(2-sin((clock)*2*pi))*4)*25),
> >.
> >.
> >.
> >
> >(or worse) does that count as using functions?
> 
> No. All that stuff gets evaluated at parse time. It doesn't affect the
> speed of the rendering.
I would expect so.

> The various frames take different amounts of time to render, but only
> because the object varies in size. In particular, on my machine, the
> time to render a frame with clock=0 containing lots of things like
>   <-0.785398,0.000000,0.000000>,1-(exp(-(2-sin((clock)*2*pi))*4)*25),
> 
> renders in exactly the same time as one containing things like
>   <-0.785398,0.000000,0>,0.991613,
> 
mmm, I will try to recreate what I did. Consider this solved (category:
not a bug after all) I will repost if I can recreate the problem and 
have some measurements. Thanks for looking into it.

	Andrel

Post a reply to this message