Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
DomiRaza

rotationX doesn't fit like rotationY & rotationZ in my 3D cube test

Recommended Posts

Hello DomiRaza, and Welcome to the GreenSock Forum!

 

I do understand why you are animating each face separately, so this way the cube will be 3D even for IE, since iE does not support transform-style: preserve-3d. Glad your doing it that way ;)

 

But when you say "why the rotationX params doesn't fit like rotationY & rotationZ" .. what do you mean by doesnt fit ?

 

Also have you tried using transformPerspective on each face instead of using perspective on the cube parent?

 

Just trying to grasp what you mean by doesnt fit ?

 

Thank you for any additional information :)

Link to post
Share on other sites

I think the OP means that the some of the panels don't rotate correctly when you click the 'rotation x +45' or 'rotation x -45' buttons next to the cube.

 

I didn't even realize those were buttons the first time I looked at the pen. :)

Link to post
Share on other sites

Your rotationX might be reversed because of the other rotations. You might need to animate each face separately for that.

Link to post
Share on other sites

Thank You all for the time You spent on this topic.

  • Jonathan, actually I tried to deal with perspective or/and transformPerspective and the best solution was to put perspective for the container and transformPerspective for each face.
    'Doesn't fit' means that the action called with rotationZ or rotationY moves the whole cube whereas the rotationX action rotates each face separately.
  • PointC, thanks for Your translation ;-)
  • OSUBlake, the rotationX, rotationY and rotationZ actions already animate separately each face. Please, tell me what do You mean about 'be reversed'?

To all:

Do You think that the parameters of the command at the beginning transformOrigin:'50% 50% -100px' for each face explains why it works for rotationY & rotationZ and not with rotationX?

Link to post
Share on other sites

Just be careful about mixing perspective on the parent and also having transformPerspective on its children too. You will run into some cross browser bugs, especially in Chrome. ;)

Link to post
Share on other sites

I don't know guys - there is some weirdness here that I don't quite understand.  :huh:

 

Rather than make a cube, I made a quick pen with a single div for a simple test.

 

When you rotate that div on the x and spin it on the y, you get a flat rotating record like you'd expect. The same expected result happens if you rotate it on the y and then spin it on the z, but as soon as you rotate it on the y and spin it on the x, you get the spin happening on the z.

 

See the Pen WrwGrg by PointC (@PointC) on CodePen

Link to post
Share on other sites

Hey PointC.. that is similar to a discussion me and Rodrigo had about rotating faces for a cube several years ago.. from this Topic:

 

http://greensock.com/forums/topic/8231-animation-of-3d-cube-in-ie10-working-with-css-but-need-help-to-convert-to-gsap/?hl=clqjh#entry34695

 

Rodrigo and I were messing with the same issue, referenced with this codepen:

 

See the Pen CLqjh by rhernando (@rhernando) on CodePen

 

And my working 3d cube IE preserve-3d workaround example with GSAP:

 

See the Pen FEbzA by jonathan (@jonathan) on CodePen

 

:)

  • Like 1
Link to post
Share on other sites

Yep - that's the exact same problem you two were discussing.

 

Rodrigo's pen certainly shows the rotational behavior you'd expect, but it only works using CSS animations? This is just odd to me. Is there a reason for this or am I missing something? I didn't see Jack or Carl in on your discussion back then - is there some light they can shed on this behavior? 

Link to post
Share on other sites

It might have to do with the order of transforms within the CSS transform function, not sure though?

 

But as Rodrigo used to say.. i will leave that up to the Honorable Sensei's Jack and Carl to explain!

 

:)

Link to post
Share on other sites

yeah - this is definitely a Jack or Carl answer I'm looking forward to reading. :)

 

It's just really confuses me because in my little demo -  test1 and test2 are just opposites of each other  - you'd think it would be so easy. What is so special about that darn x axis? 

Link to post
Share on other sites

You can clearly see what I'm talking about in the pen you linked to here...

See the Pen CLqjh by rhernando (@rhernando) on CodePen

 

Click the rotate in x-axis and notice how one of the faces is reversed.

 

So why is that? Because it's a different axis. Imagine a square with an x and y axis going through it's center. So on the y axis it rotates left-right, and the x axis it rotates it up-down. Now imagine rotating that square on the x-axis, then flip the square over on it's y-axis. The rotation of the x-axis is now reversed, flipped, whatever you want to call it.

  • Like 2
Link to post
Share on other sites

I just updated my pen with a version that works like you'd expect. :)

 

rotate it flat on the x:90 and then up to the right with z:90 and it's in the same position as a y:90 and now rotates around the y axis correctly (which looks like it would be the x axis).

 

See the Pen WrwGrg by PointC (@PointC) on CodePen

Link to post
Share on other sites

@Blake - are you saying that all axis orientations come along for the ride when you rotate the div? so in your example:

 

You rotate the div on the x axis 90 degrees to lay it flat. You then animate around the y axis and get a spinning record, but if the axis orientation was relative to the newly transformed div, wouldn't the y axis now be aimed in the same direction as the z-axis was originally and the animation wouldn't work correctly?

Link to post
Share on other sites

The x-axis is the only one that gets affected.

 

I ran in this issue a while ago in this demo. Just press create, and grid of green blocks fly in. Now move your mouse across the tiles and you will notice that they flip in the direction you are moving your mouse. To figure out the the correct rotationX, whether it's positive or negative, I first had to figure out if it was reversed.

 

http://plnkr.co/edit/CIiLR4?p=preview

  • Like 1
Link to post
Share on other sites

ahhh... I see what you're saying. Cool demo BTW!  :)

 

I actually do a lot of 3D modeling and animation so my mind is always on a pos/neg orientation and x/y/z way of thinking. With 3D animation you always have the option of using local or world coordinates which makes visualizing everything pretty easy.

 

If CSS transforms were only as easy, we could transform everything into position, parent it to a null and animate anything we wanted like the 2.5D system in After Effects. :)

  • Like 1
Link to post
Share on other sites

Just to clarify guys..  in GSAP the CSS rotateZ() equivalent rotationZ is the same as using GSAP rotation :D

 

You can see in one my old pen that i use rotation instead of rotationZ:

 

See the Pen FEbzA by jonathan (@jonathan) on CodePen

 

Either one will do the same

 

:)

  • Like 1
Link to post
Share on other sites

@Jonathan - yep - understood. For some reason, I just find using the Z to be comforting. :)

  • Like 1
Link to post
Share on other sites

I guess local and global would be a good way to describe the issue. Just another reason why CSS is not on my friend's list.

 

I just noticed this demo in the thread that Jonathan linked to. Look at how he is handling rotatationX by using rotationZ on the left and right faces. I commented out the bottom 2 lines to show it without the other rotations.

 

See the Pen EPKZGB?editors=001 by osublake (@osublake) on CodePen

  • Like 1
Link to post
Share on other sites

So really what it comes down to for DomiRaza or anyone trying this type of cube is you'll have to treat the animation of those two sides differently. You won't be able to just have one transform animation on the same axis for each of the 6 panels.

  • Like 1
Link to post
Share on other sites

Yup. That's what I meant by animating each face separately. Not...

TweenMax.to("#cube figure",2,{rotationX :'+=45',ease:Back.easeOut});
  • Like 1
Link to post
Share on other sites

So... if everyone would have listened to Blake back in post #4, we could have saved a lot of typing.  :-D

Link to post
Share on other sites

That is the same way i am doing it

See the Pen FEbzA by jonathan (@jonathan) on CodePen

in that old thread i linked too as well. The needed nested div helps with rotation of its parent face, for the left and right face when rotating on the z-axis get reversed, I believe by having it nested it will place that element on a different rendering layer where it can rotate free from its parent  :blink:

 

Normally you would just set the initial position of the cube face with position (left and top) and transforms (rotate and translate). And then you just add transform-style: preserve-3d to the faces parent, and then add perspective on the main parent, animate the parent cube only, and call it a day.

 

But since we need IE to play nice, then we need to animate each face separately and use transformPerspective instead of perspective. So this way when your animating a cube it will take more effort, more carpel tunnel, and the need to create more markup for IE. But it does correct some other issues like your seeing with adding rotation on the left and right face, by using a nested child. Two birds with one stone :ph34r:

  • Like 3
Link to post
Share on other sites

Great discussion, guys. It sounds like you've got it resolved now, right? 

 

For the record (and assuming I'm understanding the question properly), it is an order-of-operation issue. Technically GSAP is more rigid than CSS in this regard because it always enforces a specific order of operation whereas CSS lets you do it many different ways. I'd argue that there's a VERY important benefit of having a predictable, consistent order of operation - you can always count on the results and you can read back the values in a predicable way.

 

For example, imagine if you checked the rotationX, rotationY, and rotationZ of an element and got a certain set of values (let's say 60, 30, 80). If the order of operation was variable (like in CSS), you could get RADICALLY different results visually even when identical values were used. If it was rotated on the x axis, then y, then z, it would look one way, but if you rotated it on the z, then y, then x, it'd look completely different. 

 

The way CSS implements 3D rotation leverages Quaternions which helps to solve gimbal lock that can taint Euler angles, but again there are tradeoffs that I personally find unacceptable. GSAP allows you to have completely independent control over each transform component, including the ability to have them controlled by different tweens that overlap. So you could animate rotationY and part-way through that animation, start animating rotationX and then rotationZ and you get consistent results across the board. I think most animators would much rather have that consistency than the flexibility in order of operation that CSS delivers. 

 

Let me know if there are any loose ends or if you guys have it all figured out already :) 

  • Like 6
Link to post
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.

×