Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Rich Shupe

Best way to allow an end-user to edit a timeline on the fly?

Recommended Posts

Hi Jack/Carl/forum gurus,

 

It's been a very long time!

 

I think I need some general platform- and tech-agnostic strategy advice about how to allow a user to edit a timeline during use. I would very much appreciate any thoughts from anyone. Please forgive me if this is long, but I hope it's not overly complicated. I just want to lay out the needed detail.

 

I need to simulate a simplified GPS-like experience with a follower on a path. For the sake of discussion, imagine a route on a map that you must walk to get from point A to point B. That's working just fine but three critical points are giving me pause.

 

  • The speed will change constantly (slowing down, speeding up, and stopping for periods of rest).
  • The user must edit the points at which the changes occur, and the times involved. The user must be able to scrub through the animation to position the follower, and then enter values into a table for the tween durations. Thereafter, the animation must be updated each tie the data is edited.
  • The total duration of the "trip" is fixed.

 

So I'm hoping for recommendations (or possibly just confirmation) on what I think is the need to REbuild the animation cyclically. I assume the best thing is to give you a few ideas of what I think I should do and invite better solutions/any points I may be missing.

 

  • My initial assumption was that the best way to do this was to build a timeline of multiple tweens. I considered adding labels to one tween but, considering other givens that I'll include, didn't see any advantage of one approach over the other. I'm open to ideas.
  • In order for the user to position the follower at any point during the editing phase, there must be an initial tween so the user can scrub a slider to move the follower along the path.
  • Ideally that time can start out as arbitrary, and I'm near certain I have to rebuild the timeline multiple times so that shouldn't matter. But it's also possible for me to insist that the user begin with the maximum time. That will be known in advance, but may change (circling back to the need to rebuild often).
  • Tweening the progress of the follower along the path will always use values of 0 to 1, and the path will never change. But the duration of each mini segment along the path will not only vary, it will likely change during editing. (E.g., the first leg is walking from house to store. Second leg is from store to park. But the author may later change that to leg 1 is running to the store, an inserted leg two will be resting for a short time, and leg three will be from store to park.)

 

I think my biggest question is how to handle the duration of the entire timeline during editing. Something like: 

 

  1. To allow the author to play immediately, create a first tween of the follower using any arbitrary time. (Assume 1 second.) Playback is inconsequential, as only the scrubber will be used to move the follower along the path. At this point, we have a timeline of one tween. If the fixed max duration is known (let's say 100 seconds), I can use that instead of an arbitrary time, but I can't see how it matters. Again, open to learning.
  2. Author adds a keyframe for leg one, which results in changing the first tween from progress 0 to 1 over 100 seconds, to from progress 0 to .10 over 10 seconds. 
  3. However, I still need the user to be able to move the follower along the entire path, so I need to create another tween--behind the scenes--to make up the rest of the journey. I can add an arbitrary time for scrubbing or, if the total time is known, add the balance. In other words, I can now add a tween from progress .10 to 1 that lasts either 1 second, or 90 seconds if I know the max duration and can subtract 10 from 100.

 

The rest is rinse and repeat. Here's a hypothetical example:

 

  1. Tween progress 0-1 for 1 second.
  2. Max time becomes known so rebuild initial tween for 100 seconds.
  3. First leg inserted, 0-0.10 for 10 seconds. Add another tween 0.10-1 for 90 seconds.
  4. Second leg inserted, 0.10 to 0.20 for 10 seconds. Rebuild resulting in three tweens, the last from 0.20-1 for 80 seconds.
  5. First leg is lengthened to 20 seconds. Rebuild resulting in three tweens, 0-0.10 for 20 seconds, 0.10-0.20 for 10 seconds, and balance of 0.20-1 for 70 seconds

 

and so on. Some obvious questions that spring to mind are:

 

Are there any compelling reasons to create one tween of the max time and rebuild each time using label positions? Is that not the same general process? 

 

Can anyone think of a better way? For example is there an easier way to cut up one master tween, rather than adding component parts to sum up the total duration, that would be easier?

 

Is there a recommended process for rebuilding the timeline upon each edit? Because I can just wipe everything out and start over, and this is during the editing process, I don't currently see a need to carefully tear anything down killing tweens, concerning myself with existing callbacks, etc. I can just "nullify" everything and start over each time, if needed. It would be very nice to be able to "rebuild" as transparently as possible, but don't want to make anything overly complicated.

 

Thanks very much for taking the time to read this. :-)

Link to comment
Share on other sites

1 hour ago, Rich Shupe said:
  • The user must edit the points at which the changes occur, and the times involved. The user must be able to scrub through the animation to position the follower, and then enter values into a table for the tween durations. Thereafter, the animation must be updated each tie the data is edited.
  • The total duration of the "trip" is fixed.

Aren't those mutually exclusive? What if the total duration is "fixed" at 100s but the user enters durations that add up to 500s?

 

It's a lot to take in and I may not be understanding you correctly, but in my mind it's one motionPath tween that you pause() and then build a separate timeline that just tweens the progress (or time) of that tween so that you can get the proper "speed up, slow down, stop for x seconds" behavior (each is a tween on the timeline). 

 

As for tearing down and rebuilding, yeah, I don't see any compelling reason why you'd need to only do little chunks. Just kill() the old one and rebuild a new one. 

 

Good luck!

Link to comment
Share on other sites

Sorry, Jack, I wasn't clear on the mutually exclusive issue. Total progress is obviously 0-1, no confusion there. Total time is fixed, but how it's cut up into keyframes isn't. Hence the idea of a 10-second run changing into a 20-second jog and adjusting everything thereafter.

 

Sorry, too, that there was a lot of detail. I think I at least feel like the approach is validated:

  1. Build whatever I know initially (dummy tween or known totalTime and any keyframes to date)
  2. Add a balance progress of (1-lastProgress) that takes a balance duration of (totalTime - accumulatedKeyframeDurations)
  3. Kill tweens and then start over upon the next edit.

If anyone has any ideas, I'm open to hearing them.

 

I have to say, Jack, I've been having so much fun getting back into GSAP after a prolonged absence. GSAP makes me want to create things without necessarily first having a project to drive the effort. :-)   

  • Like 1
Link to comment
Share on other sites

7 minutes ago, Rich Shupe said:

I have to say, Jack, I've been having so much fun getting back into GSAP after a prolonged absence. GSAP makes me want to create things without necessarily first having a project to drive the effort. :-)   

Yay! Welcome back, Rich. Tween responsibly. Don't forget to take some breaks to sleep occasionally. ;)

  • Haha 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×