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

waypoints
scrolling

(Mark Hunte) #22

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.


#23

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.


#24

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.


(Trey Yancy) #25

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)


(Jonathan Deutsch) #26

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

(Trey Yancy) #27

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)


(Greg) #28

You could use Hype’s gesturePhase to detect the end of the drag…

var x = event['hypeGesturePhase'];

if (x == "end") hypeDocument.continueTimelineNamed('Grow Box Timeline', hypeDocument.kDirectionForward, true);

ViewportTest_1.hype.zip (18.1 KB)


(Trey Yancy) #29

Do you know how to do a wheel script rather than drag?


(jewo1980) #30

Hi there - thanks for a great forum. My first post here, so I’m sorry if this is the wrong place or breaking any other rules :slight_smile:

I’m having trouble getting Waypoints.js to work when working with multiple waypoints - it seems like performance goes way down to the point where waypoints don’t respond unless scrolling up and down repeatedly past the point it should be activated. All the various waypoints are doing is generally getting activated when the element is at 50% height of the window.

I have read elsewhere that adjusting scrollthrottle might help but I have had no luck adjusting this.

Anyone out there that have a simple, working example of this that they could kindly share?

With regards


(Mark Hunte) #31

Hi, Could you post an example project of what you are trying to do…


(jewo1980) #32

Sure - this is a very simple example but with the same problem. The second waypoint is not responding as expected.

waypoints.hype.zip (14.8 KB)


(Mark Hunte) #33

The waypoints are working.

The main reason is you have a pause keyframe action on the second timeline…

So you need to adjust the Hype parts/ i.e what the timeline actually does.


(Mark Hunte) #34

Have a look at this

The start timeline keyframe on the main timeline is removed.

All pause keyframes removed.

The bluebox timeline now just has one animation.

Both waypoint codes now looks like this.

    $('#firkant').waypoint (function(direction){
	console.log(direction)
	if (direction == 'down') {
		
		hypeDocument.continueTimelineNamed('bluebox', hypeDocument.kDirectionForward, false)
	 
		}else  {
		
	 
		hypeDocument.continueTimelineNamed('bluebox', hypeDocument.kDirectionReverse, false)
		}
		
	}, { offset: '50%' });

waypoints mhv1.hype.zip (16.9 KB)


(jewo1980) #35

Thanks a lot.

I just assumed that you should pause the timelines to prevent them playing before the waypoint reaches the desired point in the window but I guess I misunderstood the logic here.


(Mark Hunte) #36

That may have come from you having the start bluebox timeline on the Main Timeline.

I did not see it straight away and it was confusing the heck out of me why the timeline was running when I removed the pauses.


The only type of timeline that will auto run is a Main Timeline.

All others will need to be kick started.


(jewo1980) #37

Sorry for that thing on the main timeline - this was just a quick example for the forum, and I did not notice it myself. It was the pausing of the other timelines that was the real problem.

Thanks again!