• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 40,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

Introducing Twizzle (alpha)

Christopher Mowla

Premium Member
Joined
Sep 17, 2009
Messages
1,104
Location
Earth
YouTube
Visit Channel
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

Member
Joined
Jul 6, 2007
Messages
3,618
Location
California
WCA
2006GARR01
YouTube
Visit Channel
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?
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.
 
Last edited:

bcube

Member
Joined
Sep 8, 2010
Messages
233
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

Member
Joined
Dec 24, 2015
Messages
2,477
That said, I recently rewrote all of this. Could I ask you to see if you still have the issue with the new version?
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".


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

Member
Joined
Jul 6, 2007
Messages
3,618
Location
California
WCA
2006GARR01
YouTube
Visit Channel
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".


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.
 
Last edited:

Lucas Garron

Member
Joined
Jul 6, 2007
Messages
3,618
Location
California
WCA
2006GARR01
YouTube
Visit Channel
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.
 

Lucas Garron

Member
Joined
Jul 6, 2007
Messages
3,618
Location
California
WCA
2006GARR01
YouTube
Visit Channel

Christopher Mowla

Premium Member
Joined
Sep 17, 2009
Messages
1,104
Location
Earth
YouTube
Visit Channel
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.
 
Last edited:

Christopher Mowla

Premium Member
Joined
Sep 17, 2009
Messages
1,104
Location
Earth
YouTube
Visit Channel
@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) )
 

Lucas Garron

Member
Joined
Jul 6, 2007
Messages
3,618
Location
California
WCA
2006GARR01
YouTube
Visit Channel
@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?
 
Top