I'm not sure if anyone has noticed, a rubiks cube can be represented by only the orientations of the pieces. You do this by defining their "correct" position in cube coordinates rather than piece coordinates (local about the piece center). In other words you might define a 3d model for each piece in world space assuming the cube as a whole is centered on the origin. With pieces offset from the origin like this, any rotation about an axis will appear to move the piece as well as rotate it. With 24 orientations, you'll find 3 that place a corner in the same position but colors rotated. Similarly edges have 2 orientations for each of 12 locations.
One does need to compute the traditional position of the pieces to determine which ones need to be rotated for a given move, but the total state is significantly reduced.
Tell me this isn't news to the cube world. It cant be. Can it?
Fun article! Makes me want to play with prolog again.
I put together something looking at a rubik's cube as a permutation of numbers a while back. https://taeric.github.io/cube-permutations-1.html I remember realizing that my representation essentially had some permutations of numbers that it would never hit, but wasn't sure it was worth trying to more directly model the pieces of the cube. Curious if there are advantages here that I'm ignoring.
one nice thing is that if you represent the state as a permutation matrix P, and have a matrix of starting piece locations x, rendering is just Px. Then, for smooth rotation animations, if your move is a permutation M, animation is just expm ( t logm( M)) P x with t going from 0 to 1
I'm not sure if anyone has noticed, a rubiks cube can be represented by only the orientations of the pieces. You do this by defining their "correct" position in cube coordinates rather than piece coordinates (local about the piece center). In other words you might define a 3d model for each piece in world space assuming the cube as a whole is centered on the origin. With pieces offset from the origin like this, any rotation about an axis will appear to move the piece as well as rotate it. With 24 orientations, you'll find 3 that place a corner in the same position but colors rotated. Similarly edges have 2 orientations for each of 12 locations.
One does need to compute the traditional position of the pieces to determine which ones need to be rotated for a given move, but the total state is significantly reduced.
Tell me this isn't news to the cube world. It cant be. Can it?
Unable to fully parse what you are trying to express.
> the total state is significantly reduced.
The minimal "state space" of a rubiks cube is a constant value. Any "reduction" would imply the model being reduced was inefficient.
On the topic of cool "alternative" views of rubiks I recently saw this and thought it was novel.
https://old.reddit.com/r/gifs/comments/z3okyv/the_only_way_t...
That link. This is a Celtic Knot and 92 is half of 99. I had to.
Prolog's pattern matching makes this elegant. The constraint-based approach for state space pruning is clever.
Fun article! Makes me want to play with prolog again.
I put together something looking at a rubik's cube as a permutation of numbers a while back. https://taeric.github.io/cube-permutations-1.html I remember realizing that my representation essentially had some permutations of numbers that it would never hit, but wasn't sure it was worth trying to more directly model the pieces of the cube. Curious if there are advantages here that I'm ignoring.
one nice thing is that if you represent the state as a permutation matrix P, and have a matrix of starting piece locations x, rendering is just Px. Then, for smooth rotation animations, if your move is a permutation M, animation is just expm ( t logm( M)) P x with t going from 0 to 1
I blather about the permutation matrix of a rubiks cube for a long while at https://www.hgreer.com/TwistyPuzzle/