Force CALayer's rotation direction?

Question

This one has been driving me nuts...

Considering "plane" is a CALayer, I rotate it in the X axis:

plane.transform = CATransform3DMakeRotation(180 * M_PI / 180.0f, 1.0f, 0.0f, 0.0f);

And this makes it rotate clockwise, which is perfect.

Now, at some point in time, I want it to return to 0 degrees, so I use:

plane.transform = CATransform3DMakeRotation(0 * M_PI / 180.0f, 1.0f, 0.0f, 0.0f);

The thing is... it does it anti-clockwise, which is not what I want :(

I'm guessing it uses the shortest rotation path, but even if I tell it to go to 360 degrees instead, when it's done and I tell it to restart the animation, it starts from 360 to go to 180, and it goes backwards instead of the right direction.

Is there a way to workaround that?

What I'd do in Actionscript would be:

if (plane.rotationX == 360) plane.rotationX = 0;

And it'd resume nicely, but if I do that using CATransform3DMakeRotation both transformations collide, because of the animation (I think) and it gets messed up.

Any help would be much appreciated!

Thanks

Answer 1

This question came up when I was searching to solve a similar issue. I wanted to rotate an image 180 degrees and then wanted to keeping going around for a full somersault. iOS wanted to take the shortest route back. The answer here didn't help me too much. I ended up looking up some stuff on keyPath animations and that solved my issue. Below is an example of the approach.

For the particular issue raised in the question, you'd need two different sets of keyFrameValues, one for the initial rotation and another for the second. But by putting in an intermediate value you can get the desired effect, i.e. take the longer path or force the choice of equally long paths, if that's what you want. I've left some variant code in comments, as they may help folk not familiar with CAKeyFrameAnimation follow the code / understand the range of options.

- (void) somersault;
{

    CALayer* layer = [self layer];
    NSMutableArray* keyFrameValues = [NSMutableArray array];
    [keyFrameValues addObject:[NSNumber numberWithFloat:0.0]];
    //[values addObject:[NSNumber numberWithFloat:M_PI*0.5]];
    [keyFrameValues addObject:[NSNumber numberWithFloat:M_PI]];
    [keyFrameValues addObject:[NSNumber numberWithFloat:M_PI*1.5]];
    [keyFrameValues addObject:[NSNumber numberWithFloat:M_PI*2.0]];

    CAKeyframeAnimation* animation = [CAKeyframeAnimation animationWithKeyPath:@"transform"];
    [animation setValues:keyFrameValues];
    [animation setValueFunction:[CAValueFunction functionWithName: kCAValueFunctionRotateX]];// kCAValueFunctionRotateZ]];

    [animation setDuration:0.9];
    //[animation setTimingFunction: [CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionEaseInEaseOut]];

    [layer addAnimation:animation forKey:nil];

    return;
}

Answer 2

I think your problem is down to expecting a little too much of the implicit animation system, which is basically just going to interpolate your layer property values from A to B. This is great for a wide variety of cases, but it doesn't allow you to do things like "chain" changes together in sequence. There are ways to do the latter, though they're definitely less convenient than what you're doing at the moment. Still, you might want to investigate those to do things "properly". (Start with another look at the Core Animation Guide.)

However, if you're willing to put up with a cheesy workaround, you might be able to get this to look how you want just by continuing to change the rotation angle in the same direction each time rather than setting it to a constant 0 or 180:

// you need to keep track of this somewhere in your code
// (I've made it static for simplicity, you should do something more sensible)
static long currentAngle = 0;

// rotate (another) 180 degrees
currentAngle += 180;
plane.transform = CATransform3DMakeRotation(currentAngle * M_PI / 180.0f, 1.0f, 0.0f, 0.0f);

I say "might", because something in your description doesn't really chime with how I would expect the transform to work, and there are clearly some implementation subtleties I don't properly understand. This approach may well fail. But it's trivially simple, so probably worth a try.