Need Help Simulating Cuboids

[RebelKeithy]

I'm working on a VR puzzle simulator (Youtube Video Here). So far I can create fully functional LxMxN cubes (I plan on creating square-1 and pyraminx soon. The code for making those should make most twisty puzzles "easy" to add). However they are a bit too functional, you can turn any layer even after you started shape shifting. I'm trying to think up a way to check if a layer can turn, it's a bit hard since I only own NxNxN cubes, so I'm looking for help.

The idea I had was to stop a turn if it would result in a sticker being coverd by another piece or a piece being over an empty space (imagine a 2x2x8). Though that might be problematic later on if I want to add cubes like this. Any ideas?

 

[bcube]

I´m not a programmer (and haven´t really looked at the source code to see the mathematical expression/definition of the pieces and possible moves), but Boris (the author of the pCubes) seems to be really good at it (among others).

Maybe it can be inspiring for you.

 

[mikebolt]

Congratulations on being the first person to solve a Rubik's cube in VR - I was hoping to claim that title myself.

I have a few ideas about how to simulate a variety of twisty puzzles in an abstract way, but I'm not sure if those ideas would work for "non-regular" puzzles, bandaged puzzles, etc. I would love to brainstorm a theoretical way to "model" nearly every twisty puzzle in a kind of universal format. I know that others have hinted at this before, but it's an insane undertaking.

Even the weirdest puzzles can be represented mathematically as groups, but this fact doesn't help much because you still need a way to either enumerate the members and transitions of the group, or else to calculate them as needed.

You can try to use permutation matrices. You can "calculate" the puzzle's group using its permutation matrices. However, for large puzzles, you need a way to automatically generate the permutation matrices, and then you are faced with a similar problem. For example, how would you calculate the permutation matrices for a bandaged cube? I have no idea. Also, it's not always clear or intuitive how to convert between the permutation matrix representation and a 3D visual representation. Also, if you want animated rotations, then the permutation matrices alone don't give you enough information to simulate the animated rotation (without making some assumptions).

So that's why I think that permutation matrices are the wrong approach. I think we need to have some kind of rule-based system that can determine if a group of pieces is allowed to rotate and how each piece should move and rotate if so.

 

[rokicki]

I've been thinking along these lines, and looking at some general puzzle simulators such as
Magic Tile, gelatinbrain, and pCube.

One possible start is to first define a symmetry class in 3D. (For instance, you might
use x and y moves to generate your symmetry, which generate O_h, the symmetry of
the cube in space. Or you might use the symmetry of any of the Archimedean solids.)

Then you can define your shape. Perhaps it is a sphere, or just one of the solids
themselves. The shape can be defined by planes (multiplied by the symmetry). The
key thing is the shape has a visible exterior.

Next you define cutting planes. These define your cubies. The cutting planes might
be planes, or possibly they can be solids of revolution of splines or other curves.

Next you define your moves. By default the moves will simply be all those that preserve
the shape, but you can add restrictions to this set, or extend it by jumbling moves.
Restrictions might include things like bandaging.

Once all this is done, you do some work to simulate the possible moves of the entity
using a bit of geometry and perhaps physics, generating a permutation representation
(or perhaps even just an operational black-box representation) to end up with a
useful model.

I think the key things here are:

The description should be as concise as possible, exploiting symmetry and convention
so simple things are simple, but permitting extensions for common puzzles. And the description should be *data*, not code, if possible.

The description and even initial simulation should be based on geometry, not on some
table of numbers (permutations), because visualization is important.

For instance, a Rubik's cube might be defined by something like the following:

Symmetry: cubical.
Shape: Plane (1,0,0)=30 (read, 1x + 0y + 0z = 30), multiplied by symmetry.
Cuts: Plane (1,0,0)=10 (read, 1x + 0y + 0z = 10), multiplied by symmetry.
Moves: All physically realizable that preserve shape (the default.)

Of course you still want to label your moves, color your faces, etc., and I have some
thoughts on that too, but they are too long to fit in this post.

So that's why I think that permutation matrices are the wrong approach.