Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
John Blazek

A couple odd things with translateZ

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

Hey TweenMaxers,

 

Was futzin around and prototyped up a 3d carousel (

See the Pen nceyw, by johnblazek (@johnblazek) on CodePen

also using on my personal site) that works well in Webkit, followed by Safari and maybe IE10 (it doesn't work on my VM)

 

Noticed a couple things happening when I tried to animate on the Z axis.

 

1. In lines 60-64 in the JS, I'm defaulting to use the vendor prefixes in order to get translateZ to show true perspective. 

 

Tried using this code: TweenMax.set($item, { rotationY: rY * i, z:radius }), but throws some weird positions when used.

 

2. The other weird thing is if you reference line 103 and 104, you'll notice I broke them up into 2 calls, one, a "to," and the other a "set" because when I tried combining them and animate the z axis along with rotation X and Y, once you go past rotation Y -90 degrees and 90 degrees, it spazzes out.

 

Any ideas?

 

Link to comment
Share on other sites

First of all, great job on the carousel! Looks great and it animated very smoothly for me. 

 

Regarding the z positioning, let me first just give you the quick solution, then I'll explain what I think might be happening...

 

If you want to rotate the object around a point that's pushed back in 3D space, you can use the transformOrigin, like:

transformOrigin:"50%, 50%, "+ value + "px"

GSAP even works around the Safari bug that would normally cause 3D origins to render incorrectly. 

 

Now let me explain a key concept related to 3D transforms that I think may have been affecting you...

 

TweenMax always applies transforms in a particular order whereas in css you can vary the order. For example, these two lines of css produce very different results:

transform: rotateY(30deg) translateZ(100px)
transform: translateZ(100px) rotateY(30deg)

So I think you were trying to apply things in an order that isn't the standard TweenMax way, that's all. You could get the same effect, of course, by doing the math or using transformOrigin, or you could even pass in a string to a TweenMax.set() like this:

TweenMax.set(element, {transform:"rotateY(30deg) translateZ(100px)"});

That way, you don't have to worry about any of those pesky vendor prefixes. GSAP handles it for you. 

 

The only down side to that is that when TweenMax parses the rotation or position values, they may not match what you expected. It's kinda like what happens in Flash when you set rotation to 270 or something and then you trace() it and get –90. The same matrix3d() can represent an almost infinite number of different combinations of transforms. TweenMax always parses and sets in a particular order to make things consistent. But if you apply things manually in your css in a different order, it may parse the values differently even though it'll look exactly the same visually.

 

Does that clear things up? 

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