Reproducing A Clever Animation Product, Part 3

Today I implemented a few more basic animation features and gained more insight into how the Greensock animation product probably works.

The first thing I did was add the capability to pause and continue the animation. That was trivial.

I had previously implemented a list of commands that allows the script to return all animated elements to their original states so everything could be initialized when the user asked to rerun the animation. If I wanted to run the animation in reverse I had to create yet another structure that stored the end state of each element. I did this by adding a second dimension to the bcActivitiesList array. Major element zero holds the list of beginning states while major element one holds the list of ending states. I also had to change the increment step to a negative number when needed. Clicking the rerun button resets the animation step to zero and the increment to positive one. Clicking the run in reverse button resets the animation step to its highest value and sets the increment to negative one. The pause and continue buttons work whether the animation is moving forwards or backwards. So far, so good, right?

Not right.

The way this works not the only information the script has access to for any animation step is about elements that change in some way. If we’re moving forward through the animation this isn’t a big deal because the incremental changes naturally proceed from their initial state. If we walk through the animation in reverse, though, what might we know about the state of an element in the step before we’ve modified it for the first time? We might not know anything, except for the initial value we store in the initialization array. I therefore reasoned that the tween functions should each inset a copy of the initial state into the list of updates in the animation step before modifications begin (assuming they begin after step zero).

This actually works well–if the animation sweeps through every animation step in reverse. That happens when the user clicks on the run in reverse button but it might not happen if the animation step is set to an arbitrary value.

Enter the slider bar.

I added a slider bar with the idea of allowing the user to be able to set the animation to an arbitrary point. First, the slider is only available in browsers that support HTML5, but for my purposes that’s a minor issue. A bigger issue is the previously-mentioned lack of state information for every element during every time step. The slider moves with the animation and when the user moves it when the animation is not running on its own. Moving the slider by hand only returns a value when the user stops moving and releases the slider, which will leave the animation step at an arbitrary value. If no update was performed during that step for a given element then that element might not reflect the state it’s supposed to be in.

This indicates that, in order for the slider mechanism to work properly, the state of each element has to be entered into the activity list for every animation state. This isn’t actually a big deal if the number of animated elements is small, but I wonder how things would look as the number of animated elements grows. What are the limits to the complexity and number of elements we might be able to handle smoothly? (Think of the animated fountain of green balls shown in the Greensock demo linked above.) Those are questions for next week. In the meantime here is the demo in its current state. Play around with it and let me know if you see the same things I do.

And, here is the code in its increasingly entropic glory.