RE: animation

On Fri, 2002-07-19 at 14:44, CARVALHO Luis Passos wrote:
> 
> > -----Original Message-----
> > From: Greg Copeland [mailto:[email protected]]
> 
> 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. :)

Cute.  Now was a good time for some humor..so thanks!

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

Excellent!

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

Okay. Cool.  I thought as much but wanted to make sure we were on the
same page.

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

Good.  I think that makes/allows for much more flexibility.  I'll
explain more below as I saw you also touch on this again.

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

Excellent again!  This, I wasn't so sure we were on the same page.  I'm
happy to hear we are!

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

Again, thanks!  ;)

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

Again, excellent!  Yes, it was previously mentions and therefore I
assumed that we would allow for dynamic attribute/meta data/whatever you
want to call it creation and manipulation.

> > 		attribute3 = blah : start_spot_light.py
> > 			attribute4 = qwerty
> 
> We can do something like that as well, once we code it.
> 

What can I say, you're making me a happy camper!

> > 
> > > We can't backup any object property a script changes. 
>> > Properties that are only 
> > 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?

This is where having some form of cache interface comes into place. 
Seems to make sense to me to have kpov handle it and simply allow
scripts to assert it's notion of data that needs to be cached.  More
than likely there will be a minimum set of attributes which are required
to be cached (perhaps even different requirements per object type).  At
any rate, a script should have a fairly good idea of what data needs to
be communicated for kpov to represent a static scene.  After all, kpov
still has to export the resulting scene to it can be rendered!  Right?!

When I think of kpov handling animation, I imagine either a slider or
dial which advances through time.  As it advances though time, kpov also
advances through it's "time cache".  Each tick allows kpov to extract
the attributes that each script/per object (perhaps the sum of the
script results per object) deemed required for that particular tick in
time.  Once all scripts for a given object has chewed on data for a
given tick in time, the resulting data which has been communicated back
to kpov now acts as the interpolated data which kpov is now able to
statically represent for that tick in time.  Wow, that's a mouthful. 
It's assumed that the cache will maintain some form of persistence
between kpov invocations.  Otherwise, that could become cost prohibitive
for very complex scenes and we'd be back to running through all the
scripts to determine interpolated data for that given case.

Now then, moving the slider/dial allows kpov to represent the static
scene as last computed via any scripts.  This means that kpov doesn't
have to constantly re-run scripts to recalculate interpolated
data...unless the user decides he wants to do this and/or kpov has some
form of script to dirty cache detection mechanism.

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

I think the cache approach will allow us to avoid that nasty situation. 
If what I'm talking about isn't obvious...as I'm fully aware I'm still
in rambling brainstorming mode...let me know.  I'm currently planning on
writing something up in a little more detail which hopefully will better
explain the concept as well as lay down many of the assumptions that I'm
currently making...which may not be shared assumptions.  I did, however,
want to ensure that we were at least on the same page before I write
something up which would simply be ignored.  :)

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

Ah ha!  That's exactly why you may want to get away from ticks and start
looking at other objects data!  By doing this, it allows the artist to
focus on a single baseline event and then artistically derive a series
of other events.  This becomes a powerful tool in facilitating trigger
based animations rather than clock based animations whereby algorithms
are always forced into a time based application.

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


Sure!

Let's say I'm not EXACTLY sure when two objects in a scene will
collide.  Sure, I can probably go about figuring it out, but perhaps I'd
really rather not work on the physics part of it.  In stead, I have my
two objects check on each other's attributes to let them know then have
collided.  When the objects detect that they are within collision
distance, they simply set an attribute which flags the collision has
occurred.  Then, I can start a new series of actions based on the
toggled attribute..  Without this, I suddenly have to know exactly what
tick in time every event takes place and react accordingly.  By dodging
that ball, I can now be event focused.  I think that addresses your,
"...let the artist focus on art..." (paraphrase), comment rather well1
:)  While I'm just now starting to put my mind around the event based
animation concept, the more I think about it, the more powerful the
concept seemingly becomes.

I can also think of some ways where particle physics rendering might be
somewhat simplified by this approach too.  That is, I would no longer be
required to have a script which is responsible for tracking every
particle on every tick and ensure that each reacts accordingly.  Rather,
I can set things in motion and let proximity trigger a cascade of
additional scripts (say for, different particle interaction) on an event
basis.  My initial impression is that this may even offer some possible
calculation optimizations.

Greg

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

iD8DBQA9OIes4lr1bpbcL6kRAsrFAJ0cQ9+ZLCdhAFEykAqmJc1nz+1wZACfcJ3Z
H1ueI0+cbsCyxFjBwhl0Huo=
=alQj
-----END PGP SIGNATURE-----