Reproducing A Clever Animation Product, Part 25

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.

This entry was posted in Tools and methods and tagged , , . Bookmark the permalink.

Leave a Reply