Rubik cubes

I've made some working Rubik cubes for Second Life, in all of the sizes above. The largest is 5x5x5. There will not be any 6x6x6 or 7x7x7, because 5x5x5 is already pushing the limit of what Second Life can handle.

There are also miniature working 3x3x3 cubes as earrings and two pairs of unscripted earrings, one pair solved and one pair scrambled.

All in my Marketplace store. The unscripted earrings are free.

There were quite a few technical challenges in doing this.

• Each cubelet was modelled in Blender in such a way that its centre — the point that it rotates about in SL — is at the centre of the whole cube. That means that the script can move the cubes by just applying rotations, without having to also change their positions.
• For the 3x3x3, there are only three geometrically different cubelets: corner, edge, and face centre. I scripted a Rubik generator object to rez 8 copies of the same corner cubelet with rotations to put them at the 8 corners of the cube, and similarly 12 edge pieces and 6 face centres. Then I linked those with the Rubik controller object, an invisible object at the centre of the cube. For the 5x5x5 there are six different cubelets, for the 4x4x4 three, and for the 2x2x2 just one, the corner piece.
• I thought about using different “faces” (in SL terms) or “materials” (in Blender terms) for the differently coloured cubelet faces. Instead I decided to use a single texture for the whole cube and use UV mapping to give each cubelet face the right colour. The texture is only 64x64, so even in laggy conditions people shouldn't see grey cubes.
• Detecting when the cube is solved is not simple. If I take a solved cube and rotate the whole thing by a quarter turn, it’s still solved, even though every cubelet rotation has changed. A quarter turn of a face centre doesn’t change the visible appearance, so that's still a solved cube. The thing to test is that on each of the six faces of the whole cube, the cubelet faces making it up are all the same colour.
• I discovered that the event queue for link messages is 64 items long.

  The script that checks now and then to see if the cube is solved sends a link message to LINK_ALL_CHILDREN asking the cubelets to report on which way their faces are pointing and what colour they are. Each of them responds with a link message. 98 of them for the 5x5x5, all near-simultaneously. Only 64 get through. There are several ways one could deal with this. One would be to ping the cubelets in a loop. Another would be to have each cubelet wait a different length of time before responding, to avoid a traffic jam. What I eventually implemented was to have the solution checker keep track of which cubes had replied, and after a time delay ping all the missing cubelets one by one.

• Data can get lost between the server and the browser.

  When I send a reset command to the 5x5x5 cube, all 98 cubelets may change their rotation at once. All of that data is sent to the browser of every avatar present. It is possible for some of those messages to get lost. The result is that although everything on the server is as it should be, on the browser some cubes fail to get reset. I guess, although I’ve not checked this, that two people looking at the same situation might see different sets of un-reset cubelets. I've only seen this happen with the 5x5x5, or when doing a reset on a lot of smaller cubes at once. There isn’t really a solution to this. As far as I can tell, everything on the server is exactly as it should be. There is no way for a script to know what is happening on anyone’s client.