# The Puzzle

This is a continuation of Puzzle Pong - Irreversible Cube I. In the first part, Josh Mermelstein posed me a series of questions about the Irreversible Cube:

Oskar van Deventer {1} presents an Irreversible Cube in his 2013 video {2} which is an ordinary 2x2x2 Rubix Cube where you are only allowed to turn any face clockwise, and only once in a row.

By the end of part 1), I had a fairly poor approximation of an isometric projection, which was able to take a set of points and turn them into tilted tiles along one of three skew planes. This was pretty good for seeing what state the cube might be in at any given stage, but it was not a true 3D rendering, meaning that my higher goals of animating a real turn were next-to-impossible.

This inspired a separate Haskell library, Cornea for isometric 3D graphing and rendering, which I discuss here. Cornea has the benefit of being easily mapped to write out either a single image or a series of images, which can be stitched together into animations.

In this post, I’ll discuss wrapping the Irreversible Cube solver from part I into something which can render animations of the cube in the process of being solved.

# Changes

Recall our custom type definitions:

The biggest change we must make from the old way of doing things is to rewrite mkRot :: Cardinality -> Axis -> Rotation to rely on a much more general rotate :: Float -> Axis -> [x,y,z] -> [x',y',z'] under the hood. That way, we can still do things like

given a turn on face  L
-> run through sideToCardinalityAndAxis s2CA(L) = (Neg, Y)
-> get cardinality Neg and axis Y
-> mkRot Neg Y -> (\[x,y,z] -> rotate (-90) Y [x,y,z])


Or, when we need to start calculating in-between frames (tweens) for our side rotation animation, we can do things like

rotateFace :: Float -> Axis -> Obj -> Obj
rotateFace <angle> <axis> (Face pts) = Face (map (rotate <angle> <axis>) pts)


Here’s the code that makes that happen.

Now we can just write twist as

# Seqeuence of Moves

As for the algorithm, seed and kids stay the same; we end up producing the sequence of moves the same way with the same call.

# Rendering a Cube

Things have changed a little bit; instead of projecting squares and skewing/translating them, we have to actually describe the four corner coordinates of a tile in able to render it in 3d space.

Recall that we store Tiles as 3-tuples describing the center of the tile in question; if a tile is on the top face of the cube, it will have coordinates $(\pm 1, \pm 1, +2)$, etc. Tiles don’t come bundled with normal vectors describing their face orientation, so there’s nothing to it here but to hard-code this logic.

We use n as a way to control how “exploded” the cube is; at the beginning I rendered cubes as n=2 to draw the cube realistically; later we can tune it up to explode the cube more and more.

# Animation

We have a couple of options here; let’s start simple and work our way up in complexity.

We can scanr and sequentially apply moves over a solvedCube to get a sequence of cubes in various staged of solved-ness.

If we write toImage <cube> <viewpoint> to return an Image px of the cube (zipped with our custom kolors color-sequence),

Then we can write an animate function. In this case, because we want to do our styling in toImage, we only need an array of [Obj]s as our input. animate accepts a series of cubes, a series of viewpoints, and a series of filenames:

This is great. Let’s call something like:

We can see the turns a bit more clearly if we explode the cube by tuning up n, as noted above:

# Animating Motion

This is pretty good, but the whole point of a real isometric projection library is the ability to draw tiles in places other than along x-y, x-z, or y-z planes. Let’s try tweening frames.

Tweening is a concept from animation wherein, given a start and end position and a desired number of inbetween frames, we can generate those inbetween frames. This is a little like interpolation, but there are lots of different easing curves out there. For now we’ll stick with linear motion, though.

We want tween to take not a beginning- and end-state cube, but instead a beginning-state cube and a Side to turn (and a number of frames across which to turn it.

swivel is just a local implementation of twist above, with an inline renderer (toTile) which returns [Obj]s instead of Cubes. We generate a sequence of angles by using toAngle from above, and then simply return a series of cubes with more and more of the desired twist angle applied to it.

Now our frames looks like:

where r the framerate, sort of - the number of frames across each turn should occur.

If we write something like

We might get something like

# Roving Camera

Just for fun, let’s create a series of views which, knowing the length of the frameset, does a complete yaw rotation. (Also we’re retuning n=3 here for a more exploded view.)

# Conclusion

These are all pretty fast to render, with the bulk of the difficulty being from running convert after a run to stitch the produced .pngs together into a gif. Presumably convert holds the frames in-memory, which gets expensive for longer animations; I found that using Codec.Picture to do the same thing in-Haskell was equally or more expensive.

• View the source code on Github.