Fix center orientation reset in picture/supercube mode

[shuantsu]

Fix center orientation reset in picture/supercube mode

Problem

In picture/supercube mode, center stickers would rotate correctly during move animations but reset to their original orientation at the end of the animation. This broke the visual continuity expected in supercube scenarios where center orientations should be preserved.

Root Cause

The issue was in the 3x3x3 KPuzzle definition where CENTERS had orientationMod: [1, 1, 1, 1, 1, 1]. This caused the orientation calculation (newOrientation) % 1 to always result in 0, effectively resetting all center orientations after each move.

Solution

Changed orientationMod from [1, 1, 1, 1, 1, 1] to [4, 4, 4, 4, 4, 4] for the CENTERS orbit. This allows center orientations to be preserved (since centers have numOrientations: 4) while maintaining mathematical correctness.

Impact

• ✅ Center orientations now persist after moves in picture/supercube mode
• ✅ No impact on normal cube solving (orientations still work correctly)
• ✅ Corners and edges were already working correctly and remain unchanged
• ✅ Minimal change with no breaking effects

Testing

Tested on experiments.cubing.net/cubing.js/twisty/supercube-arrows.html with moves like U, R, U2, etc. Center stickers now maintain their final orientation instead of resetting.

Fixes the issue introduced in commit 9cdf18f (July 2023) where the optimization for normal cubes conflicted with picture/supercube requirements.

[lgarron]

Unfortunately, treating centers as distinguishable by default would cause effects that I think people would find surprising, particularly when comparing patterns.

I have some thoughts on possible ways to do this, but unfortunately the fix cannot be as simple as a single line.

I should probably pick an ergonomic hack that allows specifying a <twisty-player> to use super patterns in the meantime, though.

[shuantsu]

Unfortunately, treating centers as distinguishable by default would cause effects that I think people would find surprising, particularly when comparing patterns.

Can you clarify the "when comparing patterns" part?

I have some thoughts on possible ways to do this, but unfortunately the fix cannot be as simple as a single line.

Make sense. But at least it was enough to fix for 3x3x3 supercube animations

You can see a demo here:
https://filipeteixeira.com.br/new/twisty_picturecube_demo/

I should probably pick an ergonomic hack that allows specifying a <twisty-player> to use super patterns in the meantime, though.

Did you notice that big cubes has a weird way of applying textures to stickers? It seems it duplicates stickers for some kind of pieces instead of really applying the texture with the correct UV map
(notice 4x4x4 and 5x5x5)

[lgarron]

Unfortunately, treating centers as distinguishable by default would cause effects that I think people would find surprising, particularly when comparing patterns.

Can you clarify the "when comparing patterns" part?

Yeah, I literally mean comparing patterns:

import { cube3x3x3 } from "cubing/puzzles";

const defaultPattern = (await cube3x3x3.kpuzzle()).defaultPattern();

const a = defaultPattern.applyAlg("R2 D' F2 R' F' L R U' B' L' F2 U2 D' F U' R2 U2 F2 L' F2 D2 R' D2 B2 L2 F2 R2");
const b = defaultPattern.applyAlg("D' F2 R2 U' F2 U2 F2 R2 D B2 L D F' U' F' R' U2 R' B' R2");

console.log(a.isIdentical(b));

With this PR, this would print false.

Did you notice that big cubes has a weird way of applying textures to stickers? It seems it duplicates stickers for some kind of pieces instead of really applying the texture with the correct UV map

Same dealio, those pieces are indistinguishable by default.

Now that we have an external use case for it, let me see if it's simple enough to implement a <twisty-player> property to request the supercube default pattern.