@alexandregeissmann wrote:
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.
@josefrichter wrote:
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.
@MarkHunte wrote:
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.
@DBear wrote:
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.
@kardog wrote:
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.
@TYancy wrote:
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 wrote:
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
@TYancy wrote:
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)
@gasspence wrote:
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)
@jewo1980 wrote:
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
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
@MarkHunte wrote:
Hi, Could you post an example project of what you are trying to do…
@jewo1980 wrote:
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)
@MarkHunte wrote:
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.
@MarkHunte wrote:
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 wrote:
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.
@MarkHunte wrote:
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 wrote:
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!
@emcee wrote:
Hi, I’ve read through this thread and am not sure about whether any implementations are suited for my needs.
I’m really thrilled with the new release of the blocs integration! Currently, I am working on embedding a few animations into the page, while hopefully having a few that would keep the current div or bloc in place while the scroll would create the parallax effect as highlighted in this thread.
Any pointers or suggestions on how to accomplish this? I imagine that some JavaScript would need to be embedded in blocs that would track a variable that would be published by the hype document.
Like: if div is in view and view played through is true then continue scrolling else continue timeline.
I don’t know JavaScript we’ll. Anyone have anything existing that may be able to work with this new integration?
This is a game changer.
@jonathan wrote:
The current Blocs beta has an option to associate scrolling to the Main Timeline in a Hype document, so it sounds like that will do what you want if it makes it into the final build
.
.