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.

At any rate, please read below.


On Wed, 2002-07-17 at 13:28, Andreas Zehender wrote:
> > It also has a procedure to compute fotogram x.
> A script should only have a function to compute the next fotogram. It doesn't 
> matter if it needs the previous one or just depends on the current time. The 
> script can depend on other scripts, so direct calculating will be almost 
> allways not possible.

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.

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".

"Next" would always be handled when next becomes "now" in reference to
the scene that is currently being rendered/computed.

> 
> > 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.  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.

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'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. 
In many cases, this meta data may have value in being visible/accessible
to other scripts and/or facets of the application (see above).

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

Greg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA9OFcJ4lr1bpbcL6kRApIHAJ4uUl7MnOnprQCJ/s7dX63lYHZR9ACfTrdd
/HZpMqG+4WMh5ndXDecCxLg=
=9RTF
-----END PGP SIGNATURE-----