I am Not Trying to Solve Rubic's Cube - The Problem I am trying to solve involves the graphics. The solution I have is a 6 x 3 x 3 ( 6 sides x 3 rows x 3 coloumns) each cube can only be attached to a single pivot point , so you can only rotate on only 1 of the X - Y - Z axis. This I can control, and effectively display and rotate a Rubic's Type Cube.

What a want my Cube to do is display a 6 Photo graphs ( 1 on each side of the Cube, sub-divided into the 3 x 3 cubes, Spin it like a Rubics Cube, and Keep the divided photo Up right on the spin, so that when the entire cube is turned to view the backside the individual photo pieces are all up-right.

Right now any "Twist" Renders the peices upside on the backside of the Cube.

I need to effectively, only remove or spin the upside images on only 1 side of a 6 sided sub cube. It may help to visualize this by taking an Actual Rubics Cube, attach Numbers to the individual cubes and spin it vertically once and the look at the backside of the rubics cube to see what I mean.

Why not render 3 * 3 * 3 Cubes with solid colors? and rotating them ? Wouldnt it be easier?

Well, that would be 3 * 3 * 3 - 1 cubes, since the center one doesn't exist but I think that approach makes more sense than trying to paint entire faces in one shot.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

Number all of the faces of an actual Rubik's Cube, like you suggested. Look at a single side. Let's say you are looking down the z axis. If you rotate the three slices perpendicular to the y (up) axis, the numbers on the face you were looking at will maintain their orientation. However, if you rotate the three slices perpendicular to the x (side) axis, you'll find that the number's orientations will, in fact, flip. Even when you rotate the slices perpendicular to the y axis, the orientation of the numbers on the faces at the top and bottom of the cube, relative to your view position, will change.

I think I get what you mean,you want to "roatate" the face of the cube to always display the picture in the correct direction correct? The way I am seeing is changing the UV coordinates that you have attribute to Flip the texture i the correct direction, so if you flip the cube it will ways face the correct direction is this what you want?

That is correct Morphex. I don't know how to lift the image off a Texture Skin from a UV-Map or how to access the Co-Ordinates. It may be simple once I know how, But since I am Just getting into 3D Graphics I am Lost at this point.

Essentially I just Need to Re-Orintate 1 of 6 images to display it upright. Can you help ?

This is how I did it: logically, the cube consists of six faces, each with nine pieces. Each face has a base orientation such that if you have a solved cube and the cube is rotated by that base orientation, you are looking at that face with the texture oriented right side up. From this view, you have four adjacent faces, each of which are called the North, East, South or West neighbor. To minimize special cases, I chose the orientations in such a way that every face is it's northern neighbor's eastern neighbor. This created a (non-unique) face adjacency table of:

Every piece has three pieces of information: which face it's texture was originally on, which part of the texture it is (upper left, upper center, upper right, etc.) and what the current orientation is. Originally each piece has an orientation I called North. Now if you take this face and rotate it right (clockwise) ninety degrees, then the upper right piece will now have the texture the upper left piece had, but it's orientation is now East rather than North. Similarly, the upper center piece now has the texture of the middle right piece, but is also oriented East rather than North, and the center just changes orientation. Basically there are two cycles of pieces that need to be swapped: UR, UL, LL, LR and UC, MR, LC, ML. With an assigned enum values of North = 0, East = 1, South = 2 and West = 3, it means that each of these right rotations needs to increment facing by 1 (mod 4).

However, rotation also requires swapping the piece information for the adjacent pieces on the adjacent faces. There are three cycles to be considered here: N.UR, E.UL, S.LR, W.LL; N.MR, E.UC, S.LC, W.ML and N.LR, E.UR, S.LL, and W.UL. (Where N.UR is the adjacent face on the north's upper right piece, etc.) Like the previous rotations, these also require a facing change, though it's not quite as simple as adding one. Moving from the west face to the north face adds 2, from the south face to the west face adds 1, from the east face to the south face adds 2 and from the north face to the east face adds 3 (all mod 4).

From here rendering each piece is a matter of taking the texture coordinates associated the piece's texture part (upper left, upper center, etc.) and offsetting them according the the orientation. If the piece's orientation is north, then the first texture coordinate should go with the first vertex, second texture coordinate with the second vertex, and so on. If the piece's orientation is east, then the first vertex should go with the second texture coordinate, and so on. Basically add the orientation value and take the modulus by four. (It might be subtract the orientation value depending if you're using clockwise or counter-clockwise winding.)