RE: animation

> -----Original Message-----
> From: Greg Copeland [mailto:[email protected]]
> Sent: sexta-feira, 19 de Julho de 2002 19:15
> To: [email protected]
> Subject: Re: animation
> 
> 
> I'm still playing catch up on the ML, so if some of this was already
> covered else where, please take it with a grain of salt.
>

Not too salty though. It's bad for the heart. ;)
What a sorry excuse for a joke. Oh well... better to keep my day job. :)
 
> 
> Correct me here, but wont there still be a clock available?  Without a
> central clock, object synchronization, especially if done 
> with distinct
> scripts, would be very problematic.
> 

There will be a clock available. We were referring to fotograms but that
doesn't make much sense. Better to focus on time. Then we can render
fotograms at a given frequency, effectively changing the speed of the film.

> I'm going to assume that we do use some form of 
> clock/ticks/cycles/etc. 
> Based on that assumption, you would actually be computing the current
> scene and not the next one.  That is, "this" is what my current known
> starting values are, "this" is what time it is, so I know I'm supposed
> to draw everything "here", "here", and "there".
> 

This is just a difference in interpretation. What we meant was precisely
that.
The scripts would calculate the next fotogram to be rendered possibly basing
themselves on the previous rendered fotogram.

This will be a matter of personal taste of the artist. We give the
possibility to access the previous values of the objects. If the artist
chooses to make his animations depend only on time that's up to him/her.

I personally prefer to make my scripts solely dependant on time. Some people
may have different opinions. 
We aim to please. :)

> > 
> > > The script indicates it's variables, with default values, or an
> > > initialization procedure.
> > Imagine an object has different scripts. The start position 
> of the object is 
> > different for each script, so that you can't set the start 
> position in the 
> > static scene. Then you need to initialize the start 
> position anyway in the 
> > scripts initialization method. I don't see any problem if 
> not only the local 
> > variables but the objects attributes have to be initialized 
> at the scripts or 
> > animations start.
> 
> That start position should be relative to a clock or other timing
> mechanism.  That way, for multiple scripts per object, you do 
> something
> like this:
> 
> object
> 	animation scripts
> 		clock < 100 : start_ball_move.py
> 			attribute1 = xyz
> 			attribute2 = abc
> 			attribute3 = hhd
> 		clock 100-200 : funny_ball_wiggle.py
> 			attribute1 = xyx
> 			attribute2 = abb
> 			attribute3 = hha
> 		clock > 201 : surprise_ball_explosion.py
> 			attribute1 = xyy
> 			attribute3 = hdd
> 
> Any additional starting values can then be tuned by hand at 
> the start of
> a script.  

So far so good. That was what we where talking about in our mail. Each
script has start and end time. The initialization procedure is run when the
script becomes active.

Now comes the juicy part... :) Animation has so much meat to stick your
teeth in. yum...
Any vegetarians please pardon this image and replace meat with a nice tasty
vegetable salad. ;)

> When the values need to carry over, this is where 
> shared meta
> data comes into play.  

> The script would simply take care to update the
> corrosponding meta data so that other scripts which are active for a
> given clock can react, see, interact with other active 
> objects within a
> scene.
> 

Any script can access and modify all known properties of the objects so that
part of the data can be passed along from script to script. What you mean is
additional properties created for this specific scene.
We can change the objects so that we can add a set of properties to the
objects. And even serialize them.

> Also note, if meta data becomes visible to other scripts and 
> especially
> the application, you can then start to use meta data for additional
> derived synchronization events as well.  That is, something like this:
> 
> 		attribute3 = blah : start_spot_light.py
> 			attribute4 = qwerty

We can do something like that as well, once we code it.

> 
> > We can't backup any object property a script changes. 
> Properties that are only 
> > functions of the time can be computed directly and need no 
> initialization. 
> > All other properties that are changed by the script and 
> depend on the last 
> > fotogram have to be initialized by the script.
> > 
> 
> Actually, it would be pretty easy to backup properties changed by
> scripts as long as the scripting API had facilities for doing 
> so.  This
> is exactly the area of "meta data" that I was previously 
> referring to. 
> 

But how do you save it? Do you save the current point in the animation? Just
the startup points?
All points? Maybe when we start looking at how to implement this it will be
clearer, but right now if the scripts depend on the previously calculated
scene, we'll have to run through the entire movie to get to a determinate
point in time, whatever time it takes.

> Also, as long as there is some form of central clock/timing,
> synchronization and resuming becomes a much easier task to perform.
> 

I agree with this but somehow I feel we keep missing the point.
We keep looking at the animation from a physics point of view. That locks
art out. 
Many times the artist doesn't need a perfect physics model, nor does he want
one.

Maybe we're making this more complicated than it needs to be?
Maybe access to the previous image just isn't worth it.

Can someone point an example of where it could be needed?

Regards,
Luis

List archive and information: http://mail.kde.org/mailman/listinfo/kpovmodeler-devel