Introducing Twizzle (alpha)

[Christopher Mowla]

Howdy, Christopher! Can anyone else reproduce this? How hard is it to reproduce? Is there anything special about your setup that might help explain it? Anything strange in the console?

It should be very easy to replicate. Just try to spin the puzzle as fast as you can. A few times should do it (if not just once).

 

[Lucas Garron]

This always bugged me with Twizzle. Twizzle Alpha - Throwing puzzles off the screen bug (Firefox 91.0.1 on Windows 10)

Thanks for reporting!

(In general, it would help to know more details if you wouldn't mind filing an issue using a template on GitHub. But this thread is totally fine if you prefer; we'd rather hear about issues than not. :-D)

Oh, I've been getting that bug a bunch too. Just drag it up and down a bunch and the puzzle vanishes. Nothing shows up in the console for me, though. (Also Firefox; I thought I managed to reproduce it in Chrome before, but I can't get it to happen now.)

Maybe the coordinates turned into a sea of NaNs or something; if you change the puzzle geometry, the puzzle starts rendering again (because all the coordinates are recomputed?), but if you only change the cuts, the puzzle remains unrendered.

So, I've tried a bunch in Firefox both on macOS and Windows in a VM, but I haven't been able to reproduce this.
There is definitely an issue with gimbal lock in the 3D library we're using. There's a workaround that's supposed to solve it, but I'm not super confident about it.

That said, I recently rewrote all of this. Could I ask you to see if you still have the issue with the new version?

• Visit https://experiments.cubing.net/cubing.js/twisty/twisty-player-v2/
• Set camera-latitude-limit to 90.
• Spin the player and see if you can cause the issue.

If you do, a screencap of the debugging elements on the right might help.

On another note, I think it'd be nice if the puzzles could have fully free rotation, rather than only two adjustable Euler angles (one of which is constrained to ±90°). Hovering face labels (like CubeDB has) would also be very nice.

Given what I've learned from having latitude limits in alg.cubing.net, I believe very strongly that the camera should be constrained by default.
That said, it's certainly possible that this is important enough for some use cases, so we'll probably evaluate this more at some point.

(Also, note that the latitude is locked to ≈±35° by default. Twizzle Explorer uses 90° right now, but you'll have to use a JS console to unlock that on other pages. The command for this is experimental and subject to change, but I can document it in a GitHub issue if anyone wants.)

I also definitely have plans for face labels, but that will probably take a few months unless someone would like to jump in and contribute.

 

[bcube]

This always bugged me with Twizzle. Twizzle Alpha - Throwing puzzles off the screen bug (Firefox 91.0.1 on Windows 10)

As far as I remember, this behavior has also been always present at https://alg.cubing.net/ in Firefox on Windows (sorry for duplicating if that´s what you were implying).

I think it'd be nice if the puzzles could have fully free rotation.

For users who want to play with the puzzle, a rotation of separated layer/side (compare the edit parameter values for AnimCubeJS) would be also neat.

 

[xyzzy]

That said, I recently rewrote all of this. Could I ask you to see if you still have the issue with the new version?

• Visit https://experiments.cubing.net/cubing.js/twisty/twisty-player-v2/
• Set camera-latitude-limit to 90.
• Spin the player and see if you can cause the issue.

If you do, a screencap of the debugging elements on the right might help.

Immediately managed to reproduce it, both with and without setting camera-latitude-limit. The longitude values are `null` in "orbit coordinates" and "orbit coordinates request".

https://imgur.com/OwHvGkG

I've never had this problem on alg.cubing.net (any combination of Firefox and Chrome on Windows and Linux).

Given what I've learned from having latitude limits in alg.cubing.net, I believe very strongly that the camera should be constrained by default.
That said, it's certainly possible that this is important enough for some use cases, so we'll probably evaluate this more at some point.

I remember watching one of Kevin Hays's solve analyses (quite a few years ago) and he seemed to have struggled with a.c.n's constrained camera at points. Sometimes you just want to look at the other side without rotating it the long way around first.

(Also, a lot of click-and-drag rotation implementations are kinda horrible and behave unintuitively. pCubes' implementation is one such example, and it's a massive pain trying to rotate the puzzle to how I want it to be oriented in pCubes. Roofpig's is just weird (use drag direction to determine rotation axis and drag distance to determine rotation angle), but it also always resets the camera immediately after the mouse is released. This dumb demo I wrote forever ago has more sensible rotation behaviour (although still not ideal).)

 

[Lucas Garron]

For users who want to play with the puzzle, a rotation of separated layer/side (compare the edit parameter values for AnimCubeJS) would be also neat.

There's definitely a lot to do here! I don't know if we'll end up going with exactly the same solution, but intuitive ways to input moves into all sorts of puzzles is a major goal.

Immediately managed to reproduce it, both with and without setting camera-latitude-limit. The longitude values are `null` in "orbit coordinates" and "orbit coordinates request".

https://imgur.com/OwHvGkG

Aha! The "latitude": null values are very helpful.
I've deployed a potential fix that probably won't work, but it will rule out some issues. Would you mind fully refreshing the page and seeing what you get now?

(Also, a lot of click-and-drag rotation implementations are kinda horrible and behave unintuitively. pCubes' implementation is one such example, and it's a massive pain trying to rotate the puzzle to how I want it to be oriented in pCubes. Roofpig's is just weird (use drag direction to determine rotation axis and drag distance to determine rotation angle), but it also always resets the camera immediately after the mouse is released. This dumb demo I wrote forever ago has more sensible rotation behaviour (although still not ideal).)

This is also definitely my concern for me. Many free rotation inputs are not very intuitive. Your demo is definitely going in the right direction, but I think it can easily still result in confusing angles for people, especially for any watchers who are not directly controlling the input (which is more common in videos now, as you mention). It can also make it a bit tricky to return to "normal" angles, especially on unfamiliar puzzles. I'd love to see a more thorough analysis of prior art and the relevant tradeoffs.

 

[qwr]

plotly has very usable 3d rotation. I wonder how they implement it

 

[Lucas Garron]

Aha! The "latitude": null values are very helpful.
I've deployed a potential fix that probably won't work, but it will rule out some issues. Would you mind fully refreshing the page and seeing what you get now?

Okay, I was able to find a Windows install with the issue. Turns out that my fix works after all, and I've fixed this for both alpha.twizzle.net and experiments.cubing.net/cubing.js

For anyone curious, it seems that Firefox on Windows easily reports that the mouse has moved a few pixels but that exactly 0 time has passed since the mouse was at its previous position. We calculate how fast the mouse was moving, and since the mouse moved in exactly 0 time we get a speed of Infinity. This causes further issues similar to NaN ("not a number") like @xyzzy suggested. The workaround is to ignore such mouse movements when it comes to calculating speed.

 

[bcube]

I've fixed this for both alpha.twizzle.net and experiments.cubing.net/cubing.js

I am not sure whether https://alpha.twizzle.net/edit/ is fixed, however, I was able to replicate the issue right now. Cache was cleared before testing.

 

[Lucas Garron]

I am not sure whether https://alpha.twizzle.net/edit/ is fixed, however, I was able to replicate the issue right now. Cache was cleared before testing.

Would you mind checking https://experiments.cubing.net/cubing.js/twisty/twisty-player-v2/ like @xyzzy at https://www.speedsolving.com/threads/introducing-twizzle-alpha.85019/page-3#post-1451912

 

[bcube]

I am not able to replicate the issue anymore at https://experiments.cubing.net/cubing.js/twisty/twisty-player-v2/, both with and without setting camera-latitude-limit. Well done.

 

[xyzzy]

I am not able to replicate the issue anymore at https://experiments.cubing.net/cubing.js/twisty/twisty-player-v2/, both with and without setting camera-latitude-limit. Well done.

Same here, can't replicate it any more on that specific page.

 

[Cubing Forever]

@Lucas Garron one more small request:
It would be nice if you add the "forum link" function of a.c.n over here. It helps me link algs and recons easily without having to do a bunch of formatting. Currently, that's the only thing keeping me from switching to twizzle from a.c.n.

Cheers!!

 

[Christopher Mowla]

Okay, I was able to find a Windows install with the issue. Turns out that my fix works after all, and I've fixed this for both alpha.twizzle.net and experiments.cubing.net/cubing.js

For anyone curious, it seems that Firefox on Windows easily reports that the mouse has moved a few pixels but that exactly 0 time has passed since the mouse was at its previous position. We calculate how fast the mouse was moving, and since the mouse moved in exactly 0 time we get a speed of Infinity. This causes further issues similar to NaN ("not a number") like @xyzzy suggested. The workaround is to ignore such mouse movements when it comes to calculating speed.

This doesn't sound like a good long-term resolution; but, if you are certain that the NaN error is only caused by (and will only ever be caused by) our superman turning speed of the puzzles, then it will suffice! (Just be careful!) I had no idea that Firefox on Windows was actually a special combination of colliding software that would produce the error, so I'm glad that I mentioned that to at least help you to identify the error type so quickly.

But I wasn't able to reproduce the bug anymore. I guess you exposed us supermen to green kryptonite or changed the color of the sun shining on twizzle!

But thanks! You saved a lot of page refreshes for the lot of us!

And I recall this same bug happening to me when I clicked on your 2x2x2 Hamiltonian Circuit link. I am not sure exactly what caused it to break regarding that, but if it wasn't the same cause here, this may have fixed that cause too.

 

[Christopher Mowla]

@Lucas Garron
When I clicked on the link to the pattern that Per found an algorithm to in your post on twistypuzzles, this happened. (This is the puzzle vanishing bug from before, only this time, the puzzle disappears without spinning it. Just gently turning it! You can see where I am clicking.)

Again on Windows 10 with Firefox. (Firefox just had an update. Maybe this has something to do with it? Firefox 92.0 (64-bit) )

 

[rokicki]

Thanks for the report; we'll get right on it!

 

[Lucas Garron]

@Lucas Garron
When I clicked on the link to the pattern that Per found an algorithm to in your post on twistypuzzles, this happened. (This is the puzzle vanishing bug from before, only this time, the puzzle disappears without spinning it. Just gently turning it! You can see where I am clicking.)

Again on Windows 10 with Firefox. (Firefox just had an update. Maybe this has something to do with it? Firefox 92.0 (64-bit) )

Thanks for letting us know!

Turns out we were missing the proper fix in one place (that only affected the explorer, not the editor ). I've patched that up and added a guard that should still prevent the puzzle from disappearing even if something goes wrong. Could you let us know if it's robust now?

 

[Christopher Mowla]

It didn't break when I tested it just now, so it looks like it's fixed! Thanks!

 

[abunickabhi]

Great video on explaining all the features of Twizzle by Lucas and Tom.

 

[Isaev]

Lucas Garron​

could you please add a bandaging parts visualization?

 

[Lucas Garron]

Lucas Garron​

could you please add a bandaging parts visualization?

We're definitely going to add a way to do this for puzzles like Square-1. Do you have any other particular puzzles in mind, or are you trying to visualize general bandagings?