R.P. Churchill.com

I got the basics of the fountain effect working. I defined forty elements, gave them random characteristics in a loop, set a delay of 1.5 seconds from the end of the previous animation element, then set the forty elements to begin flying on a 1.45 second setback following by a jump back 1.5 seconds. This has the effect of launching a new element every 0.05 seconds (twenty per second) for two seconds, with the elements all clearing after a further 1.5 seconds minus.

It could probably be tweaked a hair, but I hope you’ll agree that this is a respectable emulation of the effect shown on the Greensock home page. Again, I have no idea whether I’ve done this the same way they did, but it works well enough.

Here is the initialization code. The handle006 element was already in place, but I added a clear instruction with a 1.5 second delay, as described above.

I’ll work on looping back at a later date, since I’m currently doing a very long road trip to clear my mind before coming back home to get back at it. Please feel free to contact me as I’m traveling.

I sat down to add in the mods that would allow me to reproduce the fountain effect I’ve described, building on yesterday’s work, and immediately identified some issues. Those will have to be sorted out before proceeding.

The animation capability I’ve built up so far is based on pre-calculating the full state of every object for every time step. With that in mind, here are a few questions and thoughts that occur to me:

• Should the objects be created by hand or automatically?
• The motions and appearance of the objects should be slightly randomized (implicitly if elements are created by hand, explicitly if elements are created automatically).
• Should all elements be created and used once or should elements be recycled?
• If elements are recycled, how automated should the process be for doing so?
• It’s probably desirable to have a continuous rate of object creation, and ideally one that would distribute evenly over the sixtieths of seconds taken for each animation step.
• What if the goal is not an effect that lasts for a fixed duration, but one that can run continuously?
• It would be a simple enough matter to set the clock back to create a continuous effect, but how can the jump back be made so that the effect appears continuous?
• Doing that seems to require a large number of elements (say, twenty per second for some number of seconds) with a jump back defined between identical states (or identical plus one animation step).
• Each time an element is recycled it should follow the same path as it did before.
• Each element is currently visible for just under two seconds. If we want about twenty elements visible at a time that changes the creation rate to about ten per second.
• The point to jump back to is one where the full complement of elements is visible, so that has to be a least two seconds into the animation.
• The animation would have to run at least a further two seconds to get to a point where it can replicate the original state.
• In theory, therefore, the whole thing could possibly be pulled off with as few as twenty elements.
• How could a meta-time be specified that would allow the loop to run for a longer but finite duration, skip the jump backwards, allow all the elements to disappear from the viewing window, and allow a new animation to start?
• Should the meta-time be specified in terms of time (e.g., seconds) or number of repeats?
• If the number of repeats is used to govern the process, how does that affect the placement in time of subsequent events, if any?
• Looking at the example that I’m emulating again, I see that the elements appear to stay on screen for only about one second each rather than two. That means that elements should be created at the rate of about twenty per second instead of ten and the loop may only need to be half as long.

I could probably go on, but this line of thinking suggests at least an initial course of action, which I’ll pursue going forward.

Today I added a new effect and applied it to a top tween that makes up the latest addition to the animation. The effect is based on this equation from the first class you take in physics:

x = x_o + v_ot + at²/2

where:

x = location
x_o = initial location
v_o = initial velocity
a = acceleration (due to gravity in this example)
t = time (in animation steps)

Note that when working in screen coordinates, positive numbers increase going down. Here’s the code I added to the processEffect function.

I had to tune the values for the initial velocity and acceleration so the path of the moving element covered most of the designated screen area and most of the designated time. It should be possible to invert the equation so that the extents of the desired path and time span are specified and the values for initial velocity and acceleration are back calculated to achieve the desired results.

Here’s how the effect is defined by the user. I added a simultaneous sideways motion to make the text look a bit like a projectile (think of a cannonball). I initialized the affected element to start just below the bottom of the demo window and the element finished somewhere below the bottom of the demo window as well. If I put a bunch of these together in the right way I can replicate the fountain-like effect on the Greensock home page (it starts at about the halfway mark).

Today I changed the form of specifying a tween effect. It was originally specified as a string (e.g., “linear” or “vibrate_right”) but now it is defined as an object literal. The first member field of the object has to be effect and its value specifies the effect to be used. If the effect requires additional parameters then those may also be provided within the object literal, but defaults are provided for all values so they aren’t strictly necessary.

Here is the code for the processEffect function I described yesterday. As noted in the comments it’s kind of annoying to have to peel the effect description objects apart every time this routine is called, but that can be improved later by creating some external state variables. Whether you as a developer would want to pursue that course of action is a matter of taste. Do you want more speed or to use less memory?

Now that this is in place it can (theoretically) be used to modify a wide variety of tweens. The code for each type of modification need only be written once.

Here’s the animation with a new block showing that the vibrate effect works as intended. There are a lot more twists I could put on this thing but the basics are working for now.

I want to make the handling of the mMethod parameter in the bcDefineWhateverTween function more flexible and modular. As you can see in the code below, the parsing of the different types of methods or applied effects has to be handled in every tween definition. Even worse, the code all has to be peeled apart and processed in every individual case.

Therefore, I’m going to try to define a wrapper function that takes the mMethod parameter, and the values for pStart, pEnd, alpha, omega, and i, and return the desired output value for that animation step. I think we’re giving up the need to peel apart the mMethod during every call in order to get a more streamlined expression where the animation step values are assigned and the ability to have to only use a single copy of the code in all tweens.

Note that this approach is expected to work for numeric tweens. It is not necessary for tweens that merely change state in a single step (like the display CSS parameter). This approach may or may not prove troublesome for other types of tweens.

I’m thinking the new version of the bcDefineWhateverTween function should look like this:

Note that in the first example, in the code as it currently exists, that the left parameter is incremented in the linear case and set absolutely in the vibrate_right case. We therefore have to come up with a consistent treatment for generating results with the proposed processEffect function. I believe it will be preferable to generate the result in a form that can be used in an absolute assignment.

The last subject I wanted to explore was animation effects, which is to say defining tweens that proceed from beginning to end in a fashion that is other than linear, which is the default I’ve been using to this point. The tweens are defined using the addTransformToList function, as shown in multiple instances below.

If, instead of defining a linear tween, we wanted to define one that behaved differently, we’d have to provide an alternate string or object literal. The information would have to include as many parameters as required to govern the desired effect. Here’s one I did for an animation on one of my intro pages; it simply specifies a string and the details are hard-coded in the tween function (in this case a bcDefineLeftTween function).

The idea is that the element would start in a given spot, get kicked to the right by some specified amplitude, vibrate back to the original position in a sine wave pattern, with a vibration having a specified period, and with a specified decay (during which the vibration gets smaller and smaller). I used parameters to govern the amplitude (the 100.0, in pixels), period (the 0.3, modifying the cumulative angle), and decay (the (omega-i) / (omega-alpha) term) so I might define an object literal of the form:

If I wanted the vibrate starting to the left I would just change the sign of the last term in the first line of the relevant block like this:

This would make the tween start in the original location but as the quantity i – alpha began to increase the cosine value would first go negative instead of positive.

The tween definitions here aren’t bad but we’d certainly want to implement something more modular. We wouldn’t want to have to embed all that specialized code in each function that defines a tween, we’d probably want to use a functional parameter that gets its parameters set in one place, then is called in the tween function using a standard-looking interface that takes only the alpha, omega, and i values as inputs. Any other method would involve too much duplication of code.

If you are wondering, this is implemented in the Greensock product in a very powerful way. They’ve created a page which lets you see how it all works in detail, here. As I’ve stated before, the folks who’ve created this product have done such a nice job with it, and their licensing terms are so easy, that it would be crazy to try to reverse-engineer or duplicate the whole thing.

One type of effect I do want to create involves simulating gravity, so that when you give an element an initial velocity moving upward, a downward velocity increment is added during every animation step. Combined with a modest leftward or rightward movement, an object can be made to “fly” in a natural-looking arc. A bunch of objects animated together in this way could be made to look like a fountain of sorts. See here (the effect starts about halfway through the title animation) for the inspiration for this exercise, which will begin next week.

Today I added the capability of adding a rotation tween, which I applied to a fourth element at the end of the previous animation. The tween definition is here:

Here’s the code added to handle rotations in the addTransformToList function. The only interesting bit is ensuring the default starting value is properly initialized.

Here are the initializations for the elements and animations.

The animation works as expected.