Jump to content
Search Community

Fluid zoom between images

Guest jasonjustice
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Guest jasonjustice

There is a slight hesitation in my animation when the first image has completed its zoom and is hidden while the next image in the sequence is made visible. Any suggestions? I'm thinking a negative overlap but I can't get it to work. Thanks.

See the Pen MvLgjb by jason-justice (@jason-justice) on CodePen

Link to comment
Share on other sites

Interestingly, that's natural phenomena when you scale things like that. Even though GSAP is animating the scale perfectly linearly, it appears to kinda slow down at the end because the pixels on the outer edges are moving away from the center faster. You can see this more clearly by using a single tween and extending the duration to 5 and make it scale to something really big, like scale:30. Notice what happens toward the end - things appear to slow down, but if you console.log() the scale, you'll see that GSAP is animating the values correctly. 

 

I'm sure there's a good math solution and I don't have time to research it at the moment, but I crafted a CustomEase that gives better results: 

CustomEase.create("zoom", "M0,0,C0.41,0.33,0.708,0.57,1,1");

 

Here's a fork: 

See the Pen 16f413605fc87a7a1b46180757229a3f by GreenSock (@GreenSock) on CodePen

 

If you want to tweak the ease, just go to: https://greensock.com/ease-visualizer?CustomEase=M0,0,C0.41,0.33,0.708,0.57,1,1

 

Does that help? 

  • Like 5
Link to comment
Share on other sites

6 hours ago, OSUblake said:

Ha! So freaky. I couldn't make sense of it. This one definitely had me stumped.

 

6 hours ago, GreenSock said:

Yeah, I was scratching my head for a bit too, @OSUblake. Totally non-intuitive (at least to my brain). 

 

Does anyone else realize how dangerous this thread was? Jack and Blake almost broke their brains at the same time. That was a close call. 

  • Like 2
Link to comment
Share on other sites

Guest jasonjustice

Thanks all. The basic zoom through the images concept was taken from another site but I wanted to use GSAP so I could have easier control of the timeline.

 

@GreenSock I had a feeling it might be that. Your custom ease looks pretty awesome.  Thank you.

Link to comment
Share on other sites

Guest jasonjustice
On 8/31/2017 at 11:25 PM, GreenSock said:

Interestingly, that's natural phenomena when you scale things like that. Even though GSAP is animating the scale perfectly linearly, it appears to kinda slow down at the end because the pixels on the outer edges are moving away from the center faster. You can see this more clearly by using a single tween and extending the duration to 5 and make it scale to something really big, like scale:30. Notice what happens toward the end - things appear to slow down, but if you console.log() the scale, you'll see that GSAP is animating the values correctly. 

 

I'm sure there's a good math solution and I don't have time to research it at the moment, but I crafted a CustomEase that gives better results: 


CustomEase.create("zoom", "M0,0,C0.41,0.33,0.708,0.57,1,1");

 

Here's a fork: 

See the Pen 16f413605fc87a7a1b46180757229a3f by GreenSock (@GreenSock) on CodePen

 

If you want to tweak the ease, just go to: https://greensock.com/ease-visualizer?CustomEase=M0,0,C0.41,0.33,0.708,0.57,1,1

 

Does that help? 

Hey @Carl I had to double the size of my images and now the slight pulse is back. Can you tell me a little bit more about how to arrived at this ease? and maybe how to increase it equally for images that are now double in size? 

Link to comment
Share on other sites

When I created that ease, it was basically trial-and-error. I visualized the portions that needed to go slower/faster and just tweaked the curve accordingly and tried it out. Copy-and-paste the values from the ease visualizer (the code at the bottom, just the numeric values for the CustomEase). That's all that needs to change. 

 

If you have a demo with the new sizes, we can take a peek, but yeah, that's the general idea (trial and error). There's probably some mathematic way of figuring it out, but I don't have the time to invest in that at the moment :)

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

Hey everyone on this thread. First off, my account got shut down. I had to re-register. Second, thanks again for all the help. I thought you'd all like to see the finished product: https://www.xbox.com/en-US/games/worlds

 

As you can see, there is a slight stutter when one image object is switched to alpha 0 and the next one to alpha 1. (It wasn't the easing BTW. It was simply just having more and larger images. Makes it more of a memory hog). I realize it's crazy to have a timeline with 99 images but this is what I was given. If anyone has any recommendations for improving performance please post here. I'll get a pen set up that isolates the animation. 

  • Like 1
Link to comment
Share on other sites

On 9/22/2017 at 1:42 PM, Jason Justice said:

yeah tablets have been a problem. newer ipads have been ok. anything more than a year old is having problems still. any suggestions from the community appreciated. thanks!

 

I think what you're doing might be better using video. Animating a bunch of large images probably won't perform well on most mobile devices.

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...
On 9/1/2017 at 2:25 AM, GreenSock said:

Interestingly, that's natural phenomena when you scale things like that. Even though GSAP is animating the scale perfectly linearly, it appears to kinda slow down at the end because the pixels on the outer edges are moving away from the center faster. You can see this more clearly by using a single tween and extending the duration to 5 and make it scale to something really big, like scale:30. Notice what happens toward the end - things appear to slow down, but if you console.log() the scale, you'll see that GSAP is animating the values correctly. 

 

I'm sure there's a good math solution and I don't have time to research it at the moment, but I crafted a CustomEase that gives better results: 

 

I have experienced similar issues with scaling, losing countless days trying to figure out the issue... going as far to even question if GSAP is the problem. Your observation was a HUGE clue into what the problem was.

 

Scale values change at an even rate, but what those values affect don't. As scale increases, the rate of change decreases, causing an animation to slow down. Linearly, there's a difference of 500 between these two changes, but their scale factors are completely different.

 

100% to 600% - 6x bigger

500% to 1,000% - 2x bigger

 

To get a perceptually correct increase in scale, you need to scale exponentially. And by exponentially, and I'm not talking about using a Expo ease, but by increasing the scale by a constant factor for a given time constant.

 

It's not hard, but it's also not built into GSAP. Probably something worth looking into adding. Exponential scale seems to be a pretty important part of After Effects. Wondering why @PointC didn't mention this. :unsure:

 

Here's a remake of the original animation using exponential scale. I broke the animation down into steps, kind of like keyframes. At each step, the scale is multiplied by a scale factor, which exponentially increases the scale.

 

See the Pen VMyeqZ by osublake (@osublake) on CodePen

 

 

  • Like 2
Link to comment
Share on other sites

Here's one of the scaling problems that I could never figure out, zooming to a point. I knew my math was correct because it would work without an animation, or by using request animation frame. But every time I tried tweening to a point, the view would not end up where it was supposed to.

 

You can see what I'm talking about in this demo. When you try to zoom with your mouse wheel, the position starts to drift. This has been driving me nuts for months trying to figure out the issue.

 

See the Pen YrYzJO?editors=0010 by osublake (@osublake) on CodePen

 

 

Once I figured out that animating the scale is causing it to drift, the solution was easy. Set the scale and position to their end state and do a from tween, eliminating the potential for any drifting. I can finally do a stable zoom animation!

 

See the Pen MErWRb by osublake (@osublake) on CodePen

 

 

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

3 hours ago, OSUblake said:

It's not hard, but it's also not built into GSAP. Probably something worth looking into adding. Exponential scale seems to be a pretty important part of After Effects. Wondering why @PointC didn't mention this. :unsure:

 

Sure, blame the After Effects guy. :D

 

You nailed it with: "it's also not built into GSAP". Here's how I usually perform the calculations for those animations:

 

CgmiZJs.jpg

 

That's what I call the 1-click solution to get a bazillion new keyframes. Figuring out the math and creating the function to make it happen is best to left to true geniuses and/or residents of the Matrix.

 

Having something like that built into GSAP would be pretty darn cool. B)

  • Like 1
  • Haha 1
Link to comment
Share on other sites

1 hour ago, Jason Justice said:

I'm a little confused by this example as it applies to my project. In this latest pen, the scaling speeds up. I needed it to be consistent. 

 

If you look in the code, there are 2 timelines. The animation timeline is animating the linear timeline with some eases just because.

var tl = new TimelineMax({ paused: true });

var animation = new TimelineMax({ repeat: -1, paused: true })      
  .to(tl, 20, { progress: 1, ease: Power1.easeInOut })
  .to(tl, 15, { progress: 0, ease: Expo.easeInOut })

 

But it's definitely linear.

 

See the Pen rGpvLz?editors=0010 by osublake (@osublake) on CodePen

 

 

1 hour ago, Jason Justice said:

Also, is there any performance benefit to doing this in canvas?

 

The question should be, "Is there any performance benefit to doing this with DOM elements?"

 

Canvas will almost always perform much better as it's less work for the browser to do, uses less memory, is hardware accelerated, and most importantly, you get to decide when and how things get rendered. I'm only animating one object in that demo. Why? Because that is all I felt like using.

 

1 hour ago, Jason Justice said:

I'm still struggling with certain tablets and browsers. 

 

What browsers and tablets? And what kind of issues are you having?

 

Without knowing that, my best guess would be that those devices are running out of memory somewhere. How many images are you using? 

 

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.
×
×
  • Create New...