Andrew, I can think of several reasons why simple time-indexed animation may be a bad idea. Some important aspects of animation are usually: 1) A main use case is playback, where time change is continuous and monotonic. 2) Differential action is often much cheaper than time jumping (i.e. between adjacent time steps most lines do not move and do not need to be recomputed. It is cheaper to modify the previous animation.) 3) Time is a topological space, with lots of nice properties: change of time is a group, intervals are decomposable, etc. Animation inherits this structure as a G-torsor (e.g. between two close enough times the line art should look very similar, there is no canonical start time). You are throwing this all away if you just treat line art like a point set. 4) Although your Time set may be discrete, you may want to pretend it is smooth to facilitate e.g. motion blur and simulation, which strongly favor a differential approach. There is often a need for run-up or adaptive time interval subdivision. Clip start and stop times are often changed interactively. Instead of defining a calculus (line art indexed by time), you may want to define an algebra (action of time change on line art). You can manipulate the algebra independently for efficiency (e.g. combine adjacent time intervals into one big interval if pointwise evaluation is cheap, or subdivide an interval if differential change is cheap) and then apply the final result to line art defined at some time origin. Take a quick read of http://en.wikipedia.org/wiki/Principal_bundle where the (group) G is time change and the (fiber bundle) P is the line art. At minimum, implement your time argument as a start time + delta time, and consider a State monad (or StateT monad transformer) to hold future optimizations like cached (time,art) pairs in case you change your mind. Dan Tim Docker wrote:
It seems that the "correct" course of action is to design a DSL for declaratively describing animated line art. Does anybody have ideas about what such a thing might look like?
Someone else already mentioned FRAN and it's ilk. But perhaps you don't need something that fancy. If you implement your drawing logic as a function from time to the appropriate render actions, ie
| import qualified Graphics.Rendering.Cairo as C | | type Animation = Time -> C.Render ()
then you just need to call this function multiple times to generate sucessive frames.
Tim _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe