# Objects not rotating with each other (Rubik's cube)

I am animating a Rubik's cube, and as soon as I get to the second rotation the blocks that have previously been rotated start tripping out even though it should have been reset. I tried making the graph linear which fixed a lagging issue I had, but the blocks still start to spin instead of rotating around a single axis.

• Back in the day never had the patience to solve the cube... went for the brute force approach of dis - re - assemble (some would move the stickers lol) The internals of the cube were very clever. Blender wise have procedurally emulated the cube with a 3 x 3 x 3 matrix and scripted moves via frame change handler. Method akin to empties as axis gimbles @ center of cube. The 6 centres always remain on the ends of their respective axis. To rotate 1 or 2 sections about an axis, set child of constraints influence. Once an axis is chosen a non 90 degree multiple rot'n locks the other two. Jun 12, 2021 at 7:38
• Here's my solution for rotating multiple cubes using Geometry Nodes: Realistically randomize Rubik's Cube And here's older solutions using Animation Nodes: Animation Nodes Rubik's Cube Apr 27, 2023 at 17:45

All the small cubes of the Rubik's cube need to have their origin on the exact same point and it needs to be in the middle of the Rubik's cube. Also, when you've rotated and keyframed a face and its 6 cubes, make sure that you've also keyframed all the other cubes even if they are still, otherwise they will interpolate between other keyframes you've created for them and you may not want that.

In addition to the details provided by moonboots, use quaternion rotation mode instead of Euler. This can be set in properties/object/transform. And be careful of auto-handles; recommended is to use vector handles, set in the graph editor.

Euler rotations do not describe "shortest path" rotations; they have torque, and they have the greatest torque at 90 degree rotations. Quaternions are shortest path rotations, at least when treated as indivisible 4D vectors, but Blender's implementation, interpolating components and then normalizing afterwards, can leave you with errors with autohandles.

Edit: Downvote is probably from somebody doubting this. Here's a file demonstrating the problems from using either Euler angles or autohandle quaternions, side by side with vector handle quaternions working properly, with a 60 frame animation:

• Hello Nathan, is my answser here accurate according to you? blender.stackexchange.com/questions/129834/… ... because it seems to me impossible to create a proper rotation when the object is not aligned with the global axis, whether it is in Euler or Quaternion Jun 12, 2021 at 13:59
• @moonboots "Quaternion mode will work better than Euler but it's not perfect either" is accurate. Nothing is perfect; there will always be precision issues with rotation. However, if you do a quick test with a plane, rotated 45 degrees in edit mode, rotating in the axis of its normal, I think you'll see that vector handled quats are very, very, very close to perfect. When Blender moves all the way to quaternion slerp interp (already planned) you won't even need vector handles. Jun 12, 2021 at 15:27
• @moonboots If I wanted to be picky, where that answer is inaccurate is that global space doesn't matter whatsoever-- what matters for Euler rotation is local space. Of course, for an unparented object, those are the same spaces. Jun 12, 2021 at 15:30
• Local space is what matters but the fact that the local is not aligned with the global makes things harder to manage properly in Euler from what I understand, am I wrong? Jun 12, 2021 at 15:44
• @moonboots Depends on exactly what you mean. It's easier to manage because you can hit numpad 1 and rotate in world space. That's easier than dragging rotation numbers. But the issues with Euler torque come about because the axis of keyframed rotation disagrees with the local axes, and global axes don't enter into it whatsoever. (Note: rotating in local orientation is not rotating in local axes. Changing transform numbers is.) This is easiest to see by using a bone for easy to define local axes, where they are the rest pose axes. Jun 12, 2021 at 15:51