Viewport / Waypoint actions in Tumult Hype: Starting an animation when scrolling to an element

@nick the delay comes about because you are animating the ball using an elastic timing function. The force at the end of the elastic timing function is pretty much nil since it goes back and forth.

I’d instead not have an animation for the spring back up. You can instead change the ball to be a dynamic body immediately, and then have the plunger simply act on it.

Hi Jakob,

I tried your advise. I don't get it to work! I have the document that I practiced on attached. Any advise on what I did wrong would be much appreciated!

waypoint_test.hype.zip (33.5 KB)

Hey, @Alfie I just checked your document real quick and failed to see a reference to the “inview” library in your <head>

You need this, along with jquery and waypoints
http://imakewebthings.com/waypoints/shortcuts/inview/`

Hi @Alfie, could you please post the document if you manage to have it working ?
thanks in advance

@kerguelen
I will post the document if I get it ever to work :wink:

Still experiment with it. I am trying to get the timeline to play reverse when I scroll the waypoint out of the screen. I copied the "inview" code that @jakob advised into the header of the document but it didn't work as is. I guess I have to modify it but don't know how.

1 Like

I figured out how to get the animation to activate when scrolled to and reverse when not on screen without using the waypoints.inview, and only waypoints.

Rather than using startTimelineNamed, I use continueTimelineNamed.
$(’#redbox’).waypoint (function(){
hypeDocument.continueTimelineNamed(‘bluebox’);
}, { offset: ‘bottom-in-view’ });

Now, you must add a timeline event to pause bluebox right at the start of bluebox. Then, add another pause after it animates. Now, you must animate the box back into place, and then add another event “start timeline: bluebox”.

Lastly, go to the main timeline and add a timeline event: start timeline bluebox, sometimes doesn’t work if you put it at 0.00 so use 0.02 to be safe.

Another trick if you want the animation to go back to the start if you scroll past it is to add this:
$(’#redbox’).waypoint (function(){
hypeDocument.continueTimelineNamed(‘bluebox’);
}, { offset: ‘0’ });
The offset “0” states that when the top of the element is 0 pixels from the top of the viewport, it activates the function.

Only problem I am having is if you scroll really fast, it doesn’t finish animating that section of timeline so it get’s all backwards.

Try it out, see if you like it! I was unable to get waypoints.inview to work at all so I had to figure out a different method.

waypoints fixed.hype.zip (50.7 KB)

1 Like

Hi Ashton,

Cool idea, I need to try that option with including the reverse animation in the animation sequence and then just use the pause and continue time line function.

It sounds quite simple so hopefully I can get it to work. I really love actions and animations triggered by scrolling. It kind of gets a site alive without being required to interact with an element or object.

Thanks for sharing your ideas, much appreciated!

Alfie

Yea I didn’t put too much time into figuring out the reverse timeline, I’ll
play around with it some more too!

I love how alive a website feels when we do things like this.

Ashton

1 Like

Lovely ! Please, keep us informed of your progress !

I moved 6 posts to a new topic: Troubleshooting Embedding a Waypoints Animation

Hi Daniel,

is it possible to start several animations with different elements as “triggers” in the same layout with this method?
if yes, how you should proceed?

Thanks in advance!

Sorry for the delay in getting back to you -- the new 3.5 feature makes this very easy -- give it a go and let me know if you have issues with it.

I think @gab was talking about elements trigering actions (eg: when you scroll to this element then play that timeline, or when this element is at 50% of the scrollview, etc;) instead of the inview behaviour.

I’m interested in this also, if there is any plan of developing those behaviours built-in.

Is there a way to keep scroll position and timeline position in sync? Meaning I don’t want to start playing the animation at certain point, but instead want to move the “playhead” along the timeline (there and back) as I scroll. This is often used for various parallax effects on websites etc. Thanks.

You could look at putting hidden multiple waypoint on the scene. Which may be the easiest. But you may lose control if the window height changes.

Or you could look at getting the div, body etc (selector) scrollTop property. This tells you where the selector’s top is when scrolling

Then you would need to calculate that pixel number against your ( timeline length time and the pixel length of the scene) which you first need to probably calculate how many pixels in length to time line seconds.

Not exactly used in this way that you are asking but I understand where you're coming from.

It's easier (in parallax) manipulating the images (or divs that contain them) as these are static elements and you can just increase or decrease there position relative to the document as you scroll (using the scroll distance) As Mark said there may be a problem if the window height changes or other unforeseen changes that may effect the positioning so you have to protect against these.

That being said , I believe it can be done. Using a similar method but you have to plug in to the timeline and manipulate the timeline's current time using information gathered from the "on scroll" event.

Any way to pause initial animation and then trigger it with a waypoint when the animation is going into an iframe? I am not having much luck with this. Any suggestions would be greatly appreciated.

The documentation provides a definition of terms.

I created a timeline with a drag object that is set to control the timeline, along with an animated object that moves on to the stage, then I created a second timeline with an object that scales. I selected the animated object in the main timeline and assigned it an action that is intended to trigger the second timeline when the object enters the stage. It would seem to be simple thing, but it doesn’t work. If the documentation would provide more than definitions, that would be helpful. (Does this only work with JS - something that watches for movement of a scroll wheel? - that doesn’t work with dragging? It doesn’t say.)

ViewportTest.hype.zip (14.1 KB)

Viewport [as it presently works] is defined as the region of the window that is in view. Thus it does not take into account groups/overflow. I would like to better support this.

Your example does fundamentally work, but you need to do two things to see it in action:

  1. Remove the pause timeline action on the Grow Box Timeline (as the timeline is triggered via the viewport action). I suspect you added this pause timeline action because it was always being triggered immediately; this is from the fact that while not visible, the “scaled object” was in fact in the viewport as per the above definition.
  2. Reduce the window size to be 400px high, thus the scaled object element starts outside of the viewport

Obviously, in a real-world situation the browser window could be any height. Setting the vertical scaling to 100% in the scene editor would cause problems with relative layouts.

I put the moving object in a group that is sized to the stage and stretches vertically, and I pinned the moving object to the bottom of the group. The moving object behaved properly in relation to the stage but the resize object behaved as before.

I moved the start position keyframe to the second frame, set a new keyframe at 0 then bumped the object 1000 pixels down at the first frame and far above the viewport at the last frame. In order to add the text content, I grouped it with the moving object and assigned the vertical motion to the group.

To keep it outside the viewport and still be able to scroll content, I had to place the vertical start and end points at extreme distances. When the viewport is tall, the motion must cover more ground, which affects the speed. The shorter the window, the more reasonable the speed.

It seems that the best way to handle this is with a script that calculates the viewport size and changes the travel distance accordingly. I’d have to hire someone to handle that.

As the enter viewport action does not discriminate between direction, when the object enters from the top, it triggers the same as when entering from below. Being able to set an T/B/R/L entry direction would be helpful.

ViewportTest.hype.zip (18.0 KB)

1 Like