Jump to content
Search Community

3D-Rotation -> Fixed Axsis

Deesr 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

Hello,

I'm working on my new Portfolio at the moment, and i ran into a problem.

The whole page will be based on a cube that spins around. At first I used CSS-Transitions for the animations, but I decided to switch to GSAP JS.

 

It worked great but I got a "little" problem. It rotates the cude diffrently then it did before.

 

This it what it does: http://vps.deesr.com/cube/

This it what it should do: http://vps.deesr.com/cube/cssversion/

*You can rotate the cube with the arrow keys | (WEBKIT only for now)*

 

JS I use to rotate:

//GSAP Version
TweenLite.to(cube, 1, {rotationY: yAngle,rotationX: xAngle, ease:Quad.easeInOut});

//CSS Version
document.getElementById('cube').style.webkitTransform = "rotateX("+xAngle+"deg) rotateY("+yAngle+"deg)";

Because of this "Bug" (its more like Property) the transparents get messed up in the GSAP version.

 

It seems like the GSAP Version rotates the Axis NOT the cube itself.

 

I hope someone is able to help me.

 

Thanks

 - Deesr

Link to comment
Share on other sites

I believe the issue is simply an order-of-operation thing. In order to maintain consistency, GSAP always performs the 3D transforms in the same order but in your css case, you've flip-flopped the order. In other words:

//change this:
"rotateX("+xAngle+"deg) rotateY("+yAngle+"deg)";

//to this (different order):
"rotateY("+yAngle+"deg) rotateX("+xAngle+"deg)";

Then you'll get behavior consistent with GSAP. You can then adjust your logic appropriately for the opacity. 

 

In the css transform property, you can perform operations in any order you want, and you get very different results based on how you order things. For example, if you rotate and then translate it's very different than translating then rotating. This can be nice in certain ways, but very inconvenient in other ways, like when it comes time to parse a matrix3d(), it's virtually impossible to interpret correctly unless you always perform things in the same order. And then there's the issue of being able to individually animate each property. If they're all mashed together in various inconsistent ways, that becomes impossible to do too. One of the key features of GSAP is its ability to independently animate transforms with different timings and components, something that's impossible with css animations and transitions. For example, try creating a 2-second rotation tween and then halfway through that tween, start a 3-second scale tween with a different ease. With GSAP, that's simple. With CSS transitions/animations, it's impossible. 

  • Like 1
Link to comment
Share on other sites

Thanks for you answer!

 

I changed the order of the JS Version to the order I used in the CSS version, but it seems like it didn't change anything at all. (Uploaded it to

 

Do you know what the problem could be?

 

 - Deeesr

Link to comment
Share on other sites

No no, the order in the JS version makes absolutely no difference - that was my point. In GSAP, 3D transform components are always applied in the same order no matter how you define them in the vars parameter. I was telling you to change the order in the css version, not the JS version. 

 

Here's an excerpt from the CSSPlugin docs:

In regular CSS, the order that you list the transforms matters but GSAP always applies them in the same order for consistency: scale, then rotation (same as rotationZ), then rotationY, then rotationX, then translation (x, y, z).
  • Like 1
Link to comment
Share on other sites

Well, technically you can pass the values to GSAP using a regular "transform" property like this:

TweenLite.to(element, 1, {transform:"rotateX("+xAngle+"deg) rotateY("+yAngle+"deg)"});

But I wouldn't recommend that because the raw parsed values (rotationX, rotationY, rotation, scaleX, scaleY, etc.) won't map correctly. It may look fine in your particular case - I just wouldn't recommend this approach in general. 

 

I think a much cleaner approach is to adjust your other logic to accommodate the order in which GSAP applies things. In other words, right now you've got logic in place that is incorrectly determining which face should be visible (opacity:1). I imagine once you fix that, it'll work great. See what I mean? 

  • Like 1
Link to comment
Share on other sites

Yeah, optimizing the opacity isn't a big deal.

But the problem with this "new" Method is that i want to be able to get from page 2 to the top of the cube. This isn't possible at the moment (with 1 click).

 

Any other solutions?

 

- Deesr

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