RE: animation

On Fri, 2002-07-19 at 18:29, CARVALHO Luis Passos wrote:
> > What can I say, you're making me a happy camper!
> > 
> 
> You must understand most of this is still conceptual. It's in the
> "theoretically feasible" area.

Okay, I stand corrected!  Theoretically, I'm a happy camper!  ;)

> 
> Triggered scripts have some problems that we didn't touch. 

When I get around to writing this up in a way that's something more than
ramblings, I'll try to cover the concept as detailed as possible while
also touching on possible high level implementation concepts required to
support it.

> 	When do they end? x seconds after becoming active? When another

Well, remember, for every scene that is to be rendered, each object's
scripts will be required to fire.  This is true even if they are not
event triggered.  Triggered scripts would follow the same basic
guidelines and expectations as any other script.  A script tied to a
timer would execute for every object that it's bound to and for every
scene that is to be rendered.  Each invocation, kpov will pass it the
values that it's been told to...etc, etc, etc...

An event script would only fire when the condition that it's tied to is
true.  If you think about it, we are really saying that every script is
an event triggered script.  Think about it.  We were previously
asserting that certain scripts would only fire during certain clock
ticks.  That still an event and it's still being conditionally fired.  I
think the only difference is, one fires based on a single internally
managed event while the other fires based on a user defined and possibly
externally managed event.

Now then, the specific answer to your question is, the scripts run to
completion just like any other script.  The only catch is...again,
without giving this any amount of great thought, the event script would
be required to toggle the condition back to false when it's no longer
required.  If it's not turned off (eval false), it would fire again,
next scene, just as any other script that is supposed should.

> condition is true?
> 	They become active when the condition evaluates to true. Whenever it
> evaluates to true? Could we have two instances of the script running at
> once? *cringe*
> 

Sure you can.  Remember, the concept is one or more scripts per object
per scene to be rendered.  That means, you can have two instances of the
same script (e.g. two objects exploding) but each would be working on
two distinct object instances.  That is, it doesn't really make sense
for an object to explode twice in the same frame.  As to weather they
truly run concurrently, I don't think I have an answer to that yet.  I
will say it's certainly possible and may result in a nice optimization,
however, I have no doubt that there would be gotchas lurking within. 
For now, I think I'm content to say they don't run concurrently and
worry later about how that might be possible.

The other gotcha that I know we MAY have to deal with is order of
execution and maintaining proper state...but I think that's fairly
manageable as well.


> > 
> > 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?!
> > 
> 
> Theoretically right. How large will this file be then? 
> For an animation lasting 60 seconds we need, considering 24 frames per
> second 1440 points in time. 
> Several hundred objects in the scene, all with animations, would make the
> scene file quite big.

Well, let's put this into perspective.  What type of data will we be
needing to store.  Mostly likely, tuples containing three
ints/longs/doubles or some such type.  I think we can agree that even if
we multiply the number of points by 10, we're still not talking about a
lot of space.  That works out to be something like:  1440 (scenes) *10
(number from pocket) *3 (number in set) * 4 (bytes in a double) =
172800b or 168.75Kb.  Not hardly anything to write home about.

Of course, I fully expect it to actually take a little more than that,
nonetheless, I still don't think we're talking grossly extreme numbers.

> 
> > 
> > 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.
> > 
> 
> If we opt for the cache, we will always need to discover that the values are
> invalid.
> If you change one script, everything on the cache, from the moment that
> script is first activated, to the end of the animation becomes unusable.

Yes.  You are correct.  It would be trivial to determine what scripts
need to be re-run.  A pain in house keeping...but it can pretty easily
be done as long as the house is kept in order.  For example, all you
really need to do it track if an object is dirty or not.  On object
would become dirty if any attributes were modified.  At that point in
time, all the scripts would need to fire for each tick for that object.

This is why, having a manual mechanism as well as an optional automatic
dirty detector would be needed.  And, you are again correct in your
assertion that it's possible that ALL other scripts need to run to
properly address the changes.  This is especially true if triggered
scripts are to be supported.  At this time, you could then see which
scripts trigger on what attributes and then run those again too.  As I
said, it can be done, but the house keeping is a pain.

Then again, there are also those cases (this MS Excel here for a second)
when you know some derived values are not invalidated because of some
numbers you changed but you decide not to recalculate them until later. 
That concept would seemingly have value when applied to this situation
too.

That is, let's say I change a script that's only used on a single
ancillary object.  Do I really want to dirty the cache and cause
everything to be recalculated?  What if I have completed but one of many
changes.  I surely don't want it to automatically recalculate until I've
completed all of the required changes.

Seems like a manual recalculation is in order.

> 
> > 
> > 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 
> 
> Your intentions are very clear. Bringing them to reality is not so clear. 
> But then again where would the fun be if everything was clear?.

LOL.  Ya, that reality thing is a real PITA.  :P

> 
> Nothing is ignored. All contributions are welcome. No suggestion is too big,
> no idea too small.
> Implementing those ideas may be a different thing however.

Cool.  At this point, it sounds like everyone is at least open to talk
about this more.  I'll try to get something written up within the next
couple of days.

> 
> > 
> > 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.
> > 
> 
> Triggered scripts are indeed a very useful commodity but their semantics
> have to be very well defined before we can even think of developing them.

Yes.  The semantics would definitely have to be well defined!  I'm
certainly not opposed to helping design and/or code.  I've previously
offered and am a profession coder.

> 
> Thank you for your example. I understand the need for looking at previous
> rendered scene.

Well, what I'm proposing really isn't that exactly.  I know this is
semantics, but I want to just clarify just in case.  What I'm really
offering is a view of an object's attributes which always reflect it's
last known state.  That state may of been previously effected by one or
more scripts from any previous script invocation (any number of ticks
back), kpov it self, or even the previously mentioned initialization
stubs.  Rather, it's the cache it self which tracks state per tick.

> Now we must discover how to implement it, preferably without using up all
> available space in the users disk.
> We have to save some space so we can store the rendered images. ;)
> 

That, I think we can manage within reason.


Greg

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

iD8DBQA9OLvT4lr1bpbcL6kRAiXMAJ0cYU1E9FYQtLlE/PQ/FHjRzmYfkwCdFySF
UFZZmNso139Nf/+3Z01le/s=
=iv8I
-----END PGP SIGNATURE-----