Jump to content
Search Community

Skewing slowness

green_machine test
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

So I was playing around with a fake 3D cube-like object from just a few SVG elements. The example I've created here just changes the perspective of the cube based on the user's mouse position. There are essentially two rectangles (for the cube's top and bottom) that are being skewed in a tween. Then, another rectangle (simulating the left/right sides of the cube) has its x position tweened to match the top/bottom elements.

 

When the tween duration is small, everything looks nice and accurate. But if you change the tween duration to something larger, like 2 or 3 seconds, you'll see that the top/bottom rectangles being skewed lag behind a bit. I don't believe my calculations are the issue, since when the tweens end everything is the proper place.

 

So I'm wondering if there's anything that I'm missing here that's causing this. Something under the hood that I mixed up? A performance issue? Some law of physics with skewed objects that I'm not familiar with?

See the Pen 52bd08b9fa191a4843f1b4c7d1dc6b3a by dsenneff (@dsenneff) on CodePen

Link to comment
Share on other sites

Actually, the problem just has to do with the nature of rotational/skew values; your math was assuming the horizontal movement would progress at the same rate as the rotational/skew values, but that isn't true. Here's a quick illustration: 

 

illustration.png

 

Notice that if you skew by another 30 degrees, the movement along the horizontal axis accelerates. The interpolation between values isn't linear. It's not a GSAP thing. 

 

What I'd probably do is create a separate tween that uses a modifier which sets the skewX based on whatever the "x" value. That'll lock them in perfect sync. Instead of creating 2 tweens on every mousemove event, you can just create one that changes the "progress()" of the "real" tween that does all the work. I think it's more efficient that way. Here's an adjusted demo: 

 

 

Does that help?

  • Like 5
Link to comment
Share on other sites

Hey Jack, thanks for this!

 

I had figured that this was just a natural occurrence along the lines of what you explained with the diagram, thanks for confirming. Though, I was secretly hoping that I would be wrong and there was a parameter that would make it all better instead of reworking things.

 

Thanks a lot for this pen, your approach makes total sense now that I see it. I haven't had a chance/need to use the Modifiers plugin yet either, so it was also a good chance to learn about it while reverse-engineering your solution here. Much appreciated!

 

-darin

  • Like 2
Link to comment
Share on other sites

No problem! It was a fun challenge. 

 

FYI, you could do the same thing with an onUpdate that has a TweenLite.set() (instead of a modifier), but it's just more efficient to use a modifier because that wouldn't be creating a tween object on each tick. ModifierPlugin can come in really handy at times like this. Hopefully this was a nice excuse to familiarize yourself with it a bit and maybe it'll prove useful someday in one of your projects. 

 

Enjoy!

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...