[Haskell-cafe] Animated line art
westondan at imageworks.com
Thu Dec 4 19:49:59 EST 2008
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
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
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.
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.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe