- The Puzzle
- Seqeuence of Moves
- Rendering a Cube
- Animating Motion
- Roving Camera
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.
Recall our custom type definitions:
The biggest change we must make from the old way of doing things is to
mkRot :: Cardinality -> Axis -> Rotation to rely on a much more
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
Seqeuence of Moves
As for the algorithm,
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.
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.
We have a couple of options here; let’s start simple and work our way up in complexity.
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
Then we can write an
animate function. In this case, because we want to do our
toImage, we only need an array of
[Obj]s as our input.
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
as noted above:
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.
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.
frames looks like:
r the framerate, sort of - the number of frames across each turn should
If we write something like
We might get something like
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.)
These are all pretty fast to render, with the bulk of the difficulty being from
convert after a run to stitch the produced
.pngs together into a
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.