Today I have finished creating my Rubiks Cube program, it took around a week, and developed in c++ directX10. Using HLSL with basic texture, and 3D rendering shaders, I have successfully implemented this 3D cube.

The program is running very efficiently and can run up to 1200fps without lag, though only needed at 60fps. The three main points that kept the program efficient are:

1) Only created a single cube object that gets rendered 9 times with 9 different textures applied per frame. Hence not using high poly meshes and objs.

2) Win condition checking is O(1), since its a constant number of checks at the end of each turn. There are also two levels of checking, each are fast and simple, but the second one will not carry out unless first one has passed the check.

3) Very intuitive controls and view setup, plus the ability to see different faces whenever needed during gameplay.

There are some challenges while making this project:

- Understanding HLSL and successfully texture each face with unique texture, which ended up using TextureCube with dds files that carries generic mipmaps. For instance, I had to add a bool for switching between using flat texture vs cube map on planes vs cubes.

- Once the cubes are placed, and added lighting with shaders. Transform the cubes into right position was simple matrix rotation. But locking the arrays that carries the cube to avoid racing condition seems a little unreliable when it reaches over thousands of turns at high speed rotations.

- Control setup took a while to finalize, but the result was great, using nearly half of the keys on the keyboard, one side to select view and rotate cube, while other side to turn sections of cubes. And the turn cube keys are so intuitive it is almost like gesture control. Because of the use of number pad, for example 8->9 will turn top row right, while 8->7 will turn top row left, then 4->7 turn left column up, and 5->6 turn middle row right, etc. We even had front face turning with 0->6 and 0->4. for keyboards that do not have numb pad, a secondary key was set to center at 'J'.

- Along the way, minor things will pop up, such as when a 3x3 side has been turned 90 degrees, they need to stop at exactly 90 degrees, as even a slight percentage of degree off, will result in a not well rotated cube after a number of turns. Hence rounding functions were implemented to be performed at the end of a 90 degree turn.

- The final challenge came when solving for the win condition, as the cubes are only marked with an index, a simple solution check will not be able to handle cases where cubes are all in correct spot, but corners are turned to non-matching direction. So to fix that, an up vector was introduced for each cube, as all the edge cubes must have same up vector when solved, in combination with the index checker, this fully covers all case. Though an alternative, could be to introduce Up, Left, and Forward vector and use direction check on that plus a center check.


One interesting discovery during this was that it is possible for the cube to be looking solved, but the middle cubes are turned 180 degrees, this will not be visible during a six colored cube, but if you draw a picture, or put a up arrow on the middle pieces, you will discover that even sides are correct, but the direction or picture will be different than that of the initial setup.


The cube was a great fun game, it even has a companion cube skin texture for it, along side with customized puzzles, turn counter, timer and other stuff, probably the next challenge will be to create an AI solver for this.

Here is a picture of the cube while running...

Today I have finished creating my Rubiks Cube program, it took around a week, and developed in c++ directX10. Using HLSL with basic texture, and 3D rendering shaders, I have successfully implemented this 3D cube.

The program is running very efficiently and can run up to 1200fps without lag, though only needed at 60fps. The three main points that kept the program efficient are:

1) Only created a single cube object that gets rendered 9 times with 9 different textures applied per frame. Hence not using high poly meshes and objs.

2) Win condition checking is O(1), since its a constant number of checks at the end of each turn. There are also two levels of checking, each are fast and simple, but the second one will not carry out unless first one has passed the check.

3) Very intuitive controls and view setup, plus the ability to see different faces whenever needed during gameplay.

There are some challenges while making this project:

- Understanding HLSL and successfully texture each face with unique texture, which ended up using TextureCube with dds files that carries generic mipmaps. For instance, I had to add a bool for switching between using flat texture vs cube map on planes vs cubes.

- Once the cubes are placed, and added lighting with shaders. Transform the cubes into right position was simple matrix rotation. But locking the arrays that carries the cube to avoid racing condition seems a little unreliable when it reaches over thousands of turns at high speed rotations.

- Control setup took a while to finalize, but the result was great, using nearly half of the keys on the keyboard, one side to select view and rotate cube, while other side to turn sections of cubes. And the turn cube keys are so intuitive it is almost like gesture control. Because of the use of number pad, for example 8->9 will turn top row right, while 8->7 will turn top row left, then 4->7 turn left column up, and 5->6 turn middle row right, etc. We even had front face turning with 0->6 and 0->4. for keyboards that do not have numb pad, a secondary key was set to center at 'J'.

- Along the way, minor things will pop up, such as when a 3x3 side has been turned 90 degrees, they need to stop at exactly 90 degrees, as even a slight percentage of degree off, will result in a not well rotated cube after a number of turns. Hence rounding functions were implemented to be performed at the end of a 90 degree turn.

- The final challenge came when solving for the win condition, as the cubes are only marked with an index, a simple solution check will not be able to handle cases where cubes are all in correct spot, but corners are turned to non-matching direction. So to fix that, an up vector was introduced for each cube, as all the edge cubes must have same up vector when solved, in combination with the index checker, this fully covers all case. Though an alternative, could be to introduce Up, Left, and Forward vector and use direction check on that plus a center check.


One interesting discovery during this was that it is possible for the cube to be looking solved, but the middle cubes are turned 180 degrees, this will not be visible during a six colored cube, but if you draw a picture, or put a up arrow on the middle pieces, you will discover that even sides are correct, but the direction or picture will be different than that of the initial setup.


The cube was a great fun game, it even has a companion cube skin texture for it, along side with customized puzzles, turn counter, timer and other stuff, probably the next challenge will be to create an AI solver for this.

Here is a picture of the cube while running...