Animating a Rubiks cube problem

Hopefully I have managed to upload my blend file. My problem is described in it. If anyone has the time to take a look I would be most grateful. Thanking you in advance, John
Woops sorry I put this in the wrong animation space.


Animated Rubiks cube.blend (692 KB)

I have this problem all the time! What is it! JohnH I will try to discover the answer, but hopefully someone more knowledgable will help.

I wish I knew. It looks a little like gimble lock, something I’ve been told “doesn’t happen” in Blender.

The normal way to fix gimble lock in any 3D app would be to tweak curves in the IPO editor; with gimble lock, rotations tend to make 360 degree jumps. In this case however it seems that the local axes on some cubes showing as “Y” are in fact manipulated by “Z” in the IPO curve editor… which is kind of odd.

Am watching this thread with interest.

had the same problem, however, my solution(using bones) is of no use for you, am watching this problem with interest

In my opinion, it is just a problem due to interpolation, because there are not enough keyframes.

The simplest way to fix it is to insert a 9 degrees rotation per frame around the center of a face on the needed axis, as your faces rotates of 90 degrees each 10 frames.

In the corrected blend below,I have keyframed each frame of the last rotation : Rubiks cube Keys.blend

It is probably not the best way, and can be tedious on a long animation because it requires one key per frame, but it works.


This is how I have fixed these sort of problems before, but it seems there is something wrong, where is the unwanted rotation coming from? Does it have to do with local rotation as opposed to global?

I think that the trouble comes from the fact that at frame 1 the different cubes don’t have the same orientation. If you select each cube at frame 1 and apply to it CTRL+A, I think that the problem would be solved. Different orientations means that when selecting all the cubes of one face at frame N,and rotating them, you will rotate them around different local directions. So yes, using the Global system instead of Local seems also important in my opinion.

Thank you all for your input. I’ll give that orientation procedure a go. That seems a fair thing as I know the orientations would be all over the place. I can’t wait to get home to try it…better get back to work now.

Yes, but should this be making any difference? If one cube has Z being up, and another has Y being up then from start to finish of a turn each cube should still be turning on one local axis… these boxes are going diagonal. If it were a global key (as opposed to local) then they would still be turning on one axis only with the location being the area (if any) which could go wonky due to curvature of the movement (hence, why 45 degree turns have been keyed).
I haven’t played with it as much yet, though if CTRL-A was to work from the start, wouldn’t the boxes then all be out after the first turn?

I haven’t played with it as much yet, though if CTRL-A was to work from the start, wouldn’t the boxes then all be out after the first turn?

Yes, that’s why I’d rather use the Global axis : we don’t have to take care of the local orientation.

Well, I have tried again : I had noticed that some cubes had no key at some frames, so I have deleted all the keys,and started from scratch.

I have reset all the cubes axis with CTRL+A, and inserted a key for all cubes each 5 frames (each 45 degrees rotation).

The bad behaviour still appears when I rotate on the third axis.

I have not found the reason why…