RE: animation

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

You're too kind.

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

Hmmm... I think the only thing that was ever in discussion was the data's
ownership (script or object).
I think it's more or less settled that it is the object's data.

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

You must understand most of this is still conceptual. It's in the
"theoretically feasible" area.

Triggered scripts have some problems that we didn't touch. 
	When do they end? x seconds after becoming active? When another
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*

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

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

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

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

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.

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

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

Thank you for your example. I understand the need for looking at previous
rendered scene.
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. ;)

Regards,
Luis

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