Rubik's Cube · deepseek-v4.1-flash

Let me build this. First check the directory for three.min.js.

Let me build a Rubik's cube with Three.js. I'll use 27 cubies with colored sticker planes, rotation logic, animation, orbit controls implemented manually, buttons, scramble, reset.

Let me write the full index.html.

Key design:
- Scene, camera, renderer.
- Cube made of 27 cubies positioned at (-1,0,1) grid. Each cubie is a rounded box (BoxGeometry) with 6 materials? Better: black cubie body with colored sticker planes on outer faces. Stickers as separate meshes attached to cubie so rotating the cubie rotates stickers. "Preserve cubie and sticker state through moves" — yes.
- Actually simpler: each cubie gets 6 materials, outer faces colored, inner black. But "visible cubie boundaries" and "sticker state" — separate sticker meshes give nice rounded look and gaps. Let me do body dark box size 0.95, stickers size 0.8 planes offset 0.48.

- Face rotation: select cubies by position coordinate. Rotate around axis by 90°. Animate by creating a temporary pivot group, adding selected cubies, rotating pivot, then on completion, bake transform back into cubies by applying pivot rotation to cubie position and quaternion, then detach. Simpler: animate by rotating each cubie's position and quaternion manually via a temporary group.

Approach: create THREE.Group pivot at origin, add selected cubies to it (attach preserving world transform), animate pivot.rotation[axis], then on complete, for each child, scene.attach(child) to restore world transform, then snap positions/quaternions, remove pivot.

Using scene.attach() handles world transforms. Then remove pivot.

Let me implement move queue and disable buttons while animating.

Camera controls: spherical coords theta, phi, radius. Mouse drag rotates. Wheel zoom bounded. Reset restores camera initial.

Let me code carefully.

Face definitions:
- U: axis y, layer y=1, direction -1 (clockwise looking from +y). A clockwise U turn when viewed from above is rotation of -90° about y axis (in right-hand rule, positive rotation about y is counterclockwise viewed from +y). Clockwise from above = negative angle. So U angle = -Math.PI/2.
- D: axis y, layer y=-1, clockwise viewed from below => positive about y? Viewed from -y, clockwise corresponds to +90° about y. Let's define: for face with normal +axis, clockwise = -90°; for normal -axis, clockwise = +90°.

Let me define moves with axis vector and layer and angle sign.

Standard:
- U: +y layer, cw = -90 about y
- D: -y layer, cw = +90 about y
- R: +x layer, cw = -90 about x? Right-hand: positive rotation about +x goes from +y to +z (counterclockwise viewed from +x looking toward origin). Clockwise viewed from +x = -90 about x. yes.
- L: -x layer, cw = +90 about x
- F: +z layer, cw = -90 about z
- B: -z layer, cw = +90 about z

Inverse = opposite angle.

Prime moves use inverted angle.

Now for animation, pivot rotation about axis by current angle. For negative axis (L,D,B), angle positive.

Let me just define each move as {axis:'x'|'y'|'z', coord: 1 or -1, dir: -1 or +1} where angle = dir*90°, and for inverse dir negated.

Actually simpler: define angle directly for the quarter turn and inverse is -angle.

U: axis y, layer 1, angle -PI/2
D: axis y, layer -1, angle +PI/2
R: axis x, layer 1, angle -PI/2
L: axis x, layer -1, angle +PI/2
F: axis z, layer 1, angle -PI/2
B: axis z, layer -1, angle +PI/2

Prime: negate.

Select cubies: those whose position along axis ≈ layer (within 0.1). But after rotations, cubie positions are still on integer grid (since 90° rotations), values -1,0,1. Good. Use Math.round.

I need to fetch cubies from scene each time (not pivot children). Store cubies array globally.

Let me implement animation with requestAnimationFrame loop and a global clock. I'll use one render loop.

Animation state: current move {axis, layer, angle, pivot, selected, elapsed, duration}. On each frame, t = min(elapsed/duration,1), eased. pivot.rotation[axis] = angle*eased. When t>=1, finalize: bake.

Baking: for each cubie child of pivot, scene.attach(cubie). Then round positions, snap quaternion. Actually scene.attach keeps world transform. Positions should be exact again due to floating point; round. Quaternion may drift slightly; normalize. Rounding quaternion to nearest 90 multiple is complex. Instead snap the cubie's rotation matrix... Let me just round matrix elements. Or simpler: keep a logical state grid and set positions.

Alternative robust approach: after each move, snap each cubie's position to rounded grid and snap quaternion by constructing from rounded basis vectors.

Let me do: after attach, cubie.position.round() (Vector3.round exists? yes THREE.Vector3.round in newer versions). Then snap quaternion: get matrix, round elements, set from matrix. Three's Matrix4 has .round? Not sure. I'll manually round the 3x3 basis.

Actually floating point errors from repeated 90° rotations are tiny. Quaternion drift over many moves could accumulate. I'll snap by extracting rotation matrix elements and rounding to nearest integer for the basis vectors, then set. Let me implement.

Let me use a logical sticker state too? The requirement says preserve state through moves; physically rotating does that. Good.

For reset, easiest: rebuild cube from scratch. I'll store initial camera and rebuild.

Let me write the code.

Sticker colors: U white (+y), D yellow (-y), R red (+x), L orange (-x), F green (+z), B blue (-z).

Body material dark.

Let me create cubie:
```
const box = new THREE.BoxGeometry(0.94,0.94,0.94);
body mesh with MeshStandardMaterial color 0x111111.
```
Sticker: PlaneGeometry(0.82,0.82) with material color, positioned at face. Plane default faces +z. For +z face at z=0.48. For -z rotate PI. For +x rotate y=PI/2. etc.

Add stickers as children of cubie.

Position cubies at (x-1, y-1, z-1)? Let's center at 0: positions -1,0,1.

Camera initial: position (4.5, 4.5, 7) looking at origin. Actually let me use spherical: radius ~ 9, theta, phi. Let me set camera at (4,4.6,6.5) normalized. I'll use spherical coords:
radius=9, theta=Math.atan2(x,z) for x=4,z=6.5 -> atan2(4,6.5)=0.552, phi = acos(y/r). Let me just set theta=0.6, phi=1.0.

Camera position = target + spherical. phi from +y. x = r*sin(phi)*sin(theta), y=r*cos(phi), z=r*sin(phi)*cos(theta). phi=1.0, theta=0.6 => y=9*0.5403=4.86, sinphi=0.8415, x=9*0.8415*0.5646=4.28, z=9*0.8415*0.8253=6.25. Good.

Lights: ambient + directional.

Renderer antialias, set size to window, handle resize.

Controls: pointerdown on renderer canvas, track dragging. mousemove update theta -= dx*0.01, phi -= dy*0.01, clamp phi [0.15, PI-0.15]. Wheel zoom radius clamp [5,18].

Auto render loop.

Buttons: U U' D D' etc. Layout grid. Scramble Reset.

Scramble: generate random sequence, queue moves. Need to queue multiple moves. I'll maintain a moveQueue array. When animating finishes, shift next.

disable buttons while queue non-empty / animating. Simpler: just push to queue, buttons can always push but requirement "queue or disable further moves until it completes". Queueing is fine. But to prevent corruption, queue handles it.

I'll implement enqueue(moveName, isInverse).

Let's write.

For scramble, avoid repeating same face consecutively. Apply ~20 moves with duration maybe 150ms each for speed.

Let me code the move definitions:

```
const MOVES = {
  U: {axis:'y', layer:1, angle:-Math.PI/2},
  D: {axis:'y', layer:-1, angle:Math.PI/2},
  R: {axis:'x', layer:1, angle:-Math.PI/2},
  L: {axis:'x', layer:-1, angle:Math.PI/2},
  F: {axis:'z', layer:1, angle:-Math.PI/2},
  B: {axis:'z', layer:-1, angle:Math.PI/2},
};
```

enqueue(name, prime). angle = MOVES[name].angle * (prime?-1:1).

startMove: create pivot group, select cubies where Math.round(c.position[axis])===layer... but axis 'y' etc. Use c.position[axis]. Round. Add to pivot with pivot.attach? pivot is at origin so .attach works (THREE.Object3D.attach). Then animate.

Wait, object.attach requires it to be in scene graph. pivot added to scene. pivot.attach(cubie) preserves world transform.

Finalize: for each child (copy array), scene.attach(child). Then snap. Then scene.remove(pivot).

Snapping:
```
c.position.set(Math.round(c.position.x),Math.round(c.position.y),Math.round(c.position.z));
const m = new THREE.Matrix4().makeRotationFromQuaternion(c.quaternion);
const e = m.elements;
// round each element to nearest integer
for (let i=0;i<16;i++) e[i]=Math.round(e[i]);
c.quaternion.setFromRotationMatrix(m);
```
makeRotationFromQuaternion result elements include translation? makeRotationFromQuaternion sets rotation part and identity translation. Rounding translation elements (0) fine. Good.

But rounding elements individually might produce non-orthogonal if tiny errors... they're near exact ±1/0 so fine.

Let me also ensure stickers don't z-fight.

Now write HTML.

I'll add a title/instructions overlay.

Let me write the file.

Now let me run it in the browser. Use the browser tool. Let me inspect.

The cube looks great. Now let me test moves, inverse, orbit, reset. I'll use JS evaluation via browser? The browser tool has inspect, click, etc. It doesn't have eval. But I can test by clicking buttons and inspecting screenshots.

Let me verify the sticker state by taking a screenshot after U then U'. But precise verification via visual. Better, I can use the window.__cube hook... but no eval tool. However "inspect" returns DOM. Maybe I can add a temporary verification by using inspect? Not enough.

Actually I can test by clicking. Let me do U then U' and screenshot, and compare with initial. Since positions snap, colors should return.

Let me first click U. Button center around x=331,y=704. Then wait, then U' at x=390,y=704. Let me click.

Actually the tool may not wait for animation. Let me click then screenshot motion.

Let me click U.

The U move worked: the top layer rotated. White top, but the top-front row now shows red (came from right) and top-right shows blue (came from back). Correct clockwise U.

Now click U' to reverse. Wait for animation to finish. The click happened and returned after animation likely. Let me click U' at x=390.

The screenshot was captured mid-animation (U' in progress). That's fine. Need to wait and check final. Let me take another screenshot. Actually the click returns immediately; the motion is still running. Let me screenshot again to see final state. Maybe use "motion" action to capture frames.

U then U' returned to solved state. Top row: green front, red right, white top. Matches initial. Good.

Now test orbit by dragging background. Drag from e.g. (200,400) to (600,300). Then screenshot to see different angle. Then reset and check framing.

Orbit worked - now looking at back face (blue) and bottom (yellow). Good, shows the orbit works and camera can see back faces. But the cube is not fully visible - it's fine after dragging. Requirement "Keep the cube fully visible initially" - initially it is. Good.

Now test Reset restores initial framing. Click Reset button at x=650, y=744.

Reset restored solved cube and initial framing. 

Now test scramble. Click Scramble, wait for completion, screenshot. Also test that a move's inverse works on a non-trivial scrambled state later. Let me click Scramble and use motion to wait.

Scramble worked. The cube is messy (scrambled) but note buttons are disabled (grayed) during scramble - shown in image. Good.

Hmm, but I noticed one sticker edge looks slightly off around the middle-right: there's a red sticker that appears offset / a gap. Actually looks like a seam from perspective. Likely fine.

Wait, I notice the scramble disabled buttons; good. The screenshot shows scramble still running? Buttons grayed means scrambleActive true. The screenshot captured mid-scramble. Fine.

Now I need to verify inverse on a scrambled state. Hard to verify visually precisely. But logic is sound. Let me test move queue robustness: click multiple moves quickly. Not necessary.

One concern: the `finishMove` rounds quaternion matrix elements. For cubies rotated 90° about axes, elements are integers, good. But body geometry and stickers use groups; snapping only cubie group's quaternion. Fine.

Potential issue: `updateButtons` disables buttons during scramble only. During a single move, buttons remain enabled so users can queue moves. That satisfies "queue ... until it completes". Good.

But reset is disabled during scramble but enabled during regular moves; reset during active move: it clears queue, sets active=null, but the pivot from active move is still in scene and its children not restored. Then destroyCube traverses cubeGroup — but those children were attached to pivot, not cubeGroup! So they'd be orphaned and not removed. Bug. Similarly reset while a move is animating leaves orphan geometry.

Let me fix reset to also clean up active pivot. In reset handler, if active, remove its pivot children or just scene.remove(active.pivot). Since we destroy cube entirely, we should remove the pivot from scene too. Let me add a cleanup in destroyCube or reset: if active, scene.remove(active.pivot) and clear active. Also clear cubies array still gets destroyed? cubies array still references all 27 groups even if attached to pivot (array isn't changed). destroyCube traverses cubeGroup which no longer contains those 27, so geometry not disposed, but scene.remove(cubeGroup) leaves pivot in scene with the cubies. So orphan visible and old cube remains.

Fix: in reset handler and __cube.reset, before destroyCube, if active remove pivot from scene. But cubies are children of pivot, and destroyCube only traverses cubeGroup so won't dispose them but removing pivot removes them from scene. Then buildCube creates new. Old geometries leak but visually fine. Better: make destroyCube traverse from cubies array instead. Let me change destroyCube to dispose all cubies directly, and remove active.pivot.

Let me modify:

```
function destroyCube() {
  if (active && active.pivot) { scene.remove(active.pivot); }
  active = null;
  cubies.forEach(function(c){ c.traverse(...dispose); });
  cubies.length=0;
  if (cubeGroup) { scene.remove(cubeGroup); cubeGroup=null; }
}
```

But when not active, cubies are children of cubeGroup; disposing via cubies plus removing cubeGroup is fine. Double dispose if traverse cubeGroup too — avoid. Let me just use cubies traversal.

Also make reset function a shared function.

Let me refactor. Define `doReset()` function used by both button and window hook.

Also palette: fine.

Let me apply edits.

Note: destroyCube references `active`, `moveQueue`, `scrambleActive` which are declared later with `let`/`const` in the file (moveQueue declared after buildCube). Since destroyCube is only called at runtime after those declarations are initialized, it's fine. But `active` is declared with `let active = null;` after MOVES. buildCube/destroyCube defined before. Since functions capture the variables lexically, and are invoked after initialization, no TDZ issue.

Wait, `doReset` is defined before moveQueue/active/scrambleActive declarations too, but called at runtime. Fine.

Now reload and test reset during animation quickly. Also re-verify basic. Let me reload.

Good, reloaded fine. Now test reset during animation: click a move then immediately reset. But the click tool returns after some delay (maybe after animation). Hard to catch mid-animation via clicks. But the logic is now robust. I'll trust it.

Let me do a final verification of an inverse on a scrambled state through the exposed hook — but I can't eval. However I could use the inspect action? It only returns DOM. Hmm. Maybe the browser tool supports a way to run JS? Not listed. Let me just rely on U/U' already verified.

Actually I could add a self-test to the page that writes result to DOM title, then inspect. But that changes artifact. I could temporarily test, but time. The core logic for inverses is identical; verified U/U'.

One thing to double check: the "motion" images showed solved after U U'. Good.

Let me verify no console errors: console only shows GPU warnings (performance), no JS errors. Good.

I'm fairly confident. Let me quickly check that queueing works by clicking several face buttons rapidly via a single motion? Hard. Skip.

Let me do one more check: click F then F' and confirm solved via screenshot after enough time. Actually already verified U/U'. Good enough.

Let me finalize. Check file exists.