|
|
> Say I have a sphere, how could I generate 10 rendered images with the size
> increasing by X percent per frame?
Well, it might be easier to make it go from one size to another size over
the course of the animation, rather than a per-frame kind of thing. This can
be done with the clock variable:
#declare startsize = 2;
#declare endsize = 5;
sphere {
<0,0,0>, startsize + clock*(endsize - startsize)
// goes from 2 to 5 as clock goes from 0 to 1
...
}
And rendered with +KFI0 +KFF9 to render frames 0 through 9 (total of 10).
The clock will increase from 0 to 1 over the course of these frames.
Now, if for some reason it's really important that you do this in the
"X-percent-per-frame" way, then that can be done as so:
#declare X = 5/100; // 5%
sphere {
<0,0,0>, 2 * pow(1 + X, frame_number)
...
}
But I don't recommend this, mostly because it links the behavior of the
animation to the number of frames. It's good to be able to increase your
framerate without altering the animation itself.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
|
|
Thanks for the quick respone.
I've just experimented with the second option. I will be performing the
same action on a number of objects, so it may be easier to have initial
size that grows by 5% per frame. At the moment it's not clear how many
frames will be required. Exposing my ignorance I don't quite understand
the transformation,
2 * pow(1 + X, frame_number)
Why multiply by 2?
Related to the above, how would I apply the same to the following,
isosurface {
function{
f_rounded_box(x,y,z,0.3,1.9,0.9,0.9)
-f_marble(x*3,y*2,z*2)*0.15
-f_bumps(x*3,y*2,z*3)*0.75
}
contained_by {box {<-2,-1,-1>*2.2,<2,1,1>*2.2}}
accuracy 0.003
max_gradient 5
scale 0.7
texture{ pigment{color rgb<0.85,0.15,0.23>}
//normal {bumps 0.25 scale 0.015 }
finish {ambient 0.15 diffuse 0.75 phong 0.4 reflection 0.2}}
rotate<0,30,0>
translate <-0.2, 0.0, 0>
} // end of isosurface -----------------------------------------------
Is it possible to grow the object using the scale keyword?
"Slime" <fak### [at] emailaddress> wrote:
> > Say I have a sphere, how could I generate 10 rendered images with the size
> > increasing by X percent per frame?
>
>
> Well, it might be easier to make it go from one size to another size over
> the course of the animation, rather than a per-frame kind of thing. This can
> be done with the clock variable:
>
> #declare startsize = 2;
> #declare endsize = 5;
> sphere {
> <0,0,0>, startsize + clock*(endsize - startsize)
> // goes from 2 to 5 as clock goes from 0 to 1
> ...
> }
>
> And rendered with +KFI0 +KFF9 to render frames 0 through 9 (total of 10).
> The clock will increase from 0 to 1 over the course of these frames.
>
> Now, if for some reason it's really important that you do this in the
> "X-percent-per-frame" way, then that can be done as so:
>
> #declare X = 5/100; // 5%
> sphere {
> <0,0,0>, 2 * pow(1 + X, frame_number)
> ...
> }
>
> But I don't recommend this, mostly because it links the behavior of the
> animation to the number of frames. It's good to be able to increase your
> framerate without altering the animation itself.
>
> - Slime
> [ http://www.slimeland.com/ ]
Post a reply to this message
|
|
|
|
Disregard the second question....
I do have one other concern. Given the simple example,
#declare X = 5/100;
sphere {
<0,1,0>, 1*pow(1 + X, frame_number)
pigment{color rgb<1.0, 0.0.0.0>}
}
The first frame will have a radius of 1.05. Is the second frame calculated
using 1.05 * pow(1+X, frame_number) or is it 1.10? I need the former,
where the increase is based on the the last size.
Post a reply to this message
|
|
|
|
kmac99 wrote:
> The first frame will have a radius of 1.05. Is the second frame calculated
> using 1.05 * pow(1+X, frame_number) or is it 1.10? I need the former,
> where the increase is based on the the last size.
>
That's basic math :
Framenumber value
0 1.05^0= 1
1 1.05^1= 1.05
2 1.05^2= 1.1025
3 1.05^3= 1.157625
and so on.
If you want the sphere to grow linearly, use a
(1+frame_number*0.05)*base_radius. If you want exponential growth, use
the pow formula.
Note that you cannot base one frame calculation from precedent frame
parameters, unless you pass them from one frame to the other by a
"hand-written" file (not very easy and prevents from recalculating part
of the animation). Determining a formula available for the entire
animation is much more accurate.
Hope this helps.
Post a reply to this message
|
|