A Brief Rubik's Cube Construction Explanation

[Lin Evans]

Hi Guys,

For those who are mystified, just a brief explanation of how the Rubick's Cube is constructed using PTE.

1. Begin with a single cube as explained in my Cube Tutorial

2. Using the Parent/Child feature, combine three cubes under a single frame so that you have a single element consisting of three cubes side by side. Let's call this Cube sets A, B, and C.

3. Create three of these and place them one under the other so you end up with a total construct made with 9 cubes and place all three constructs under a parent frame. Let's call this Cube set AA

4. Create three of the nine cube constructs, each controlled by it's own frame. Call them AA, BB, CC

5. Set each of the controlling frames to respectively -47, 0, and 47 on the "Z" axis (pan Z).

Set the entire 27 cube ensemble above under a single controlling frame.

At first it will look a bit strange because you now must go to each individual "cube" in the set and turn off the "front" and "back" for cubes not seen from the outside of the individual component "cube sets."

You can can check the accuracy by rotating the individual cube sets A, B, and C as well as AA, BB, CC. When you rotate the entire 27 cube ensemble with the controlling frame using the 3D transform (X an Y) you will easily see which cube faces need to be turned off.

Rotate individual groups "AA, BB, CC" using O & A "rotation" to get the individual section "spins."

Hopefully, in the future I will have a rather complex tutorial demonstrating the construction and manipulation of the Rubik's Cube.

The above instructions covers rotation on one set of three components making up the Rubick's Cube. In order to rotate on the opposite axis, it's necessary to duplicate the entire above instruction set but using alternative cubes within the block and this construct, though identical in appearance to the first, will rotate the three alternative sets of nine cubes. However, they can't be displayed on the same "slide" so it's necessary to match the ending rotation angle, etc., with a "Quick, No Transition" on a second and subsequent slide to rotate the opposite three. So to simulate the actual Rubik's Cube action requires multiple slides.

Best regards,

Lin

[fh1805]

Hi Lin,

Interesting that your cube construction and mine are so similar. I would add the following points/comments:

I think your Pan Z value of 47 might be dependent upon some other factor. I had to use -66.6 and +66.6 to get the faces lined up properly.

Having built the first "whole cube", I then worked through it deleting all the individual cube faces that were never going to be visible. This kept the structure simple, and made subsequent work easier to manage.

Your point about needing several different builds of the cube was the aspect that required most time during construction of my sequence. It took me about 50-60 minutes to build each variant of the whole cube. I ended up using three variants. Variant 2 got rebuilt once and Variant 3 got rebuilt twice (because of orientation errors introduced inadvertently by me). Of course, prior to the final sequence that I posted there had been three previous attempts that were abandoned because I got myself into a right old mess!

I also found that a background other than black didn't work. As the cube and the layers rotate, the transparency of all the elements other than the external facets means that the background is visible "through the cube". I tried re-introducing some inner faces but this technique was not always successful due to a limitation in the current 3D Parameter implementation. Whilst you can change the Rotate X, Rotate Y and Pan Z values from one keyframe to another, the Show front and Show back settings are "Properties" of that object on that slide and cannot be changed between keyframes. For complex animation such as the Rubik's Cube, to be able to change these two values across keyframes would be a useful additional feature.

You touched upon another aspect that would be a useful additional feature. PTE does not currently support the "inheritance" of opacity across the parent-child relationship. I desperately wanted to be able to fade-in and fade-out complex constructs of objects in both the Cube sequence and in "Kaleidoscope".

I've prepared a document about my cube project (primarily for my own benefit, to have something to remind me of what I did and why) which I've attached below.

regards,

Peter

The Cube Project.doc

[Lin Evans]

Hi Peter,

I suspect that the necessity of using only a black background may be obviated by one or two possibilities. First, if one doesn't adhere to the distinct same characteristic of the mechanical Rubik's Cube and make the inside of that part of the "cube" which is seen when the nine cube sections are rotated black (transparent) then it's possible to use any convenient color for a background. I chose a light grey color for mine. Otherwise, it would probably be possible to use a black side for those cubes on the segments visible during the rotation. I just let the actual color of that particular cube show rather than a strict adherence to black. Of course this all depends on the orientation of the cube at the time of rotation of the block. What works in one position doesn't work correctly in the opposite (180 degree rotation of the entire cube) necessitating construction of alternate cube configurations if you rotate segments at specific times. It can get complicated indeed.

I used a black border surrounding each cube and this pixel space probably accounts for the difference between my -47, and 47 versus your -66 and 66. To get rid of the black as you did in your fade to a solid I would just duplicate the cube itself (one with the black individual facets to one with no facets) and fade between. Having said this, I discovered that neither -47, 47 nor -66, 66 works in all situations. Just why I've yet to discover. It could be possible that what you begin with in the form of "zoom" when you're working on the project impacts the percentages. At 100% logic dictates that 1/3rd of the total space is taken by each nine cube segment. This then should make each segment occupy 33.333 % of the total and would suggest a "push" of -66.33 and 66.33 for the "proper" figures. Why it was different for my second image than for my first I've yet to determine, but I will try to unravel the mystery.

Perhaps in a future version Igor will provide an "option" of having opacity control under the parent. For some animations such as this, it would be very, very helpful but we don't want to give up the versatility of having it like it is now also so having an option "switch" would be the way to go in my opinion.

In a true mechanical Rubik's Cube there are only 26 actual cube facets with the center one being the rotation "connector" so our simulation is slightly different in function but as they say, "good enough" I think!

In any event, it's a great simulation which you presented. If having a different colored background is important in some future animation, you might try doing it as I have - there are many ways to "skin a cat" LOL.

Here's a quick little single slides sample with only one portion of segment rotation (one of the two).

http://www.learntoma...ubik2sample.zip

Best regards,

Lin