Thread: "More MagicCube5D"

Roice Nelson wrote:

> Melinda, you are such a great motivator :) Thanks for your positive
> response and excellent feedback. The other upbeat responses were
> great too, and made me think there is enough interest from you guys to
> warrant further work on this. Plus my good friend Charlie joined me
> in the effort, which has made this even more fun to work on. I just
> posted the next incremental version we've made
> (www.gravitation3d.com/magiccube5d
> ), and have some inline
> responses and additional comments.
>
O.M.G. It's really there!!! I don't think that I can express my powerful
and conflicting emotions. It's fascinating as I know that it is a window
into a 5-dimensional world which draws me in but at the same time I want
to run away screaming.

>
>
> *Inline Comments:*
>
>
>
> * The wireframe representation does help one to see the structure
> though
> it may be harder to select stickers. BTW, the 4D stickers look *very*
> cool! With a wireframe design I'd personally prefer side-by-side
> cross-eyed stereo views otherwise you can only make out the structure
> while rotating it, but I know that is not for everyone.
>
>
> I don't think it would be too difficult to do a side-by-side stereo
> version, and so I will hope to do that at some point for you. My
> personal stereo preference is the LCD goggles (I got mine at
> www.eDimensional.com ). I've made
> Gravitation3D work with those and it'd be cool to do the same with
> this. The bummer is that they don't work with windowed programs, and
> making it a usable full-screen mode program might be a bit of work.

Well, the cross-eyed views don't require special glasses and work on all
machines including printers! It's not difficult to learn but does take a
little effort and practice. I wish that everyone could do this. Please
support this mode as soon as you get the chance and I'll offer to write
up a little tutorial on how to learn to view cross-eyed stereo.
Wireframe models look *so* cool in 3D! What looks like a confusing
jumble of lines in 2D suddenly becomes completely comprehensible in
3D--especially when rendering anti-aliased lines like you're using.
Supporting at least some version of stereo display might even turn out
to be a requirement for working with the 5D puzzle without requiring a
frustrating amount of screen rotations to visualize the structure.

>
>
> * The 3D drag rotations clearly applies all of one axis rotation
> before
> the other which makes it different to predict what will happen. I
> suggest that you use the quaternion code that I use in the Java
> version
> which makes it so that each drag increment always does what you
> naturally expect.
>
>
> I definitely agree. The current mouse handling code was just pulled
> from Gravitation3D. (I will add this suggestion to the to do list,
> but will give it lower priority than the other items that need to be
> done first to make this a workable puzzle.)

It's one of the easier things to do. Is MC5D written in C++? If so, you
can use my free version from here:
http://www.superliminal.com/sources/squat.zip. The MC4D source contains
my new Java version.

>
>
> * Instead of axis drop-downs for 5D rotations I would suggest a
> lower-triangular grid of 15 small rotate buttons.
>
>
> Charlie had wanted these quick buttons as well, and I agree with you
> guys. The drop down combos are a bit cumbersome. Charlie has already
> started doing this. I think he is planning to have 10 buttons (xy,
> xz, xu, xv, yz, yu, yv, zu, zv, uv) and to make it so left button
> clicks rotate one way and right button clicks the other. It would be
> good to allow rotations using only sticker-clicks too, but I think
> also having the buttons for convenience would be nice.

Er, 10, right. I miscounted. I suggest arranging them in a right
triangle. I like your idea of left and right clicks though I've never
seen a button that distinguished between mouse clicks. Alternatively you
could arrange 20 buttons in a 5x5 grid minus one diagonal such that the
upper buttons rotate one way and the lower ones the other but that would
make it hard to quickly undo with the mouse alone.

>
>
>
> * I suggest that toggling of individual faces should operate on their
> rotated logical positions rather than on their colors. IOW, like MC4D
> does with the outside face.
>
>
> I agreed very much with this idea too, and this is now implemented.

Very nice. Once I turned off the outermost face the rotations seem
almost comprehensible.

>
>
>
> * I understand that you wrote this mostly as a GUI feasibility
> study but
> I encourage you to give some serious consideration to working out a UI
> and implementation of a twist. I know that will be a huge task,
> and that
> once you do that you'll be all but compelled to turn it into a
> workable
> puzzle and then compelled to solve it but it would still be way
> cool to
> see some twists regardless of whether you ever take it further.
>
>
> I got a big smile reading the sentence about being compelled to do
> this stuff. It's so true and I wonder why that is sometimes.

I think it's the mountain climbing motivation. It's there and it's never
been done, therefore it must be done.

>
>
> I also wanted to let Remi know that even though there is no option to
> save the projection settings yet, Charlie is also planning to work on
> that.
>
>
>
> *Here are the changes done besides those already described above*:
>
>
>
> Charlie optimized the hell out of my nD vector class. The Debug
> version sped up by a factor of 12 and the release version by a factor
> of 4! Things are much smoother looking now.
>
Excellent though I hadn't noticed any performance problems on my modern
laptop.
FYI, Don's vector macro code is applicable for an arbitrary number of
dimensions. I think it's wonderful.

>
>
> I added sticker highlighting, in the form of making the 4-cube lines
> thicker when you mouse over stickers. If you hold down shift with a
> sticker selected, all the connected 4-stickers of that 5-cubie will
> highlight. This is really nice for gaining more intuition about the
> puzzle and how it is all connected together (idea totally stolen from
> MC4D).
>
Well your idea of using a modifier key to toggle between highlighting
one sticker or one cubie is new and very nice. I think I'll steal that
idea back!

> At the very center of the puzzle, a bunch of stickers overlap, but
> there is currently no good way to highlight specific ones.
>
>
>
> Proof-of-concept twisting: If you right or left click any sticker,
> you'll see face twisting. Unfortunately, this is not fully functional
> right now because I have not yet developed exactly how to choose the
> axes for twisting (more on that below). Right now, I just picked a
> couple of axes. However, you do get to see twisting and the mess of
> a scrambled puzzle :) A scrambled screenshot is at
> www.gravitation3d.com/magiccube5d/scrambled.png
> .
>
Very, very cool.

>
>
> Unfortunately, I broke allowing n^5 for n != 3. It should not be too
> bad to fix at some point, but I wanted to get this other stuff working
> first without worrying about that.
>
>
>
> *User Interface for the Twists:*
>
>
>
> I'd like to get the group's input on twisting control. I've been
> thinking about it off and on this past week and have what I think is a
> decent plan. But the best approach is really not clear and feedback
> would be nice.
>
>
>
> To start off (sorry if this is obvious given the recent set of
> emails), I want to point out that faces of MagicCube5D twist in the
> manner of a 4-cube. To extend the analogy of presented by MC4D, you
> remove a face, twist it any way you like in the 4 dimensions of the
> face, then put it back. But unlike 3-twists, a 4-twist needs 2 axes
> to pick a unique rotation plane. This is the main problem I've been
> having in trying to create a good user input scheme.
>
>
>
> I only finally appreciated this past week one beauty of the MC4D
> interface, which is how 4-view-rotations are done by ctrl-clicking.
> The beauty is that you only have to select a single sticker to define
> the 2 axes of the rotation. The second axis is determined implicitly
> because the rotation will always move the clicked face to the "center"
> face position. I'm not sure how the MC4D code does it, but a way to
> define faces is by their face center offsets in space coordinates. In
> MC4D, for normalized values of these, we have:
>
>
>
> +-X face (+-1,0,0,0)
>
> +-Y face (0,+-1,0,0)
>
> +-Z face (0,0,+-1,0)
>
> +-U face (0,0,0,+-1)
>
>
>
> So ctrl-clicking always involves a rotation between one of the first 6
> faces and the �U face (and you can't do a view rotation from the +U
> face). The two axes defining the plane of rotation are the 2
> non-zero values of the face offsets, from one selected face and one
> implicit face. For example, ctrl-clicking the Y face does a view
> rotation using the plane of the y and u axes.
>
>
>
> View rotations in MC5D can be done exactly the same if we want. In
> this case, the face centers are at:
>
>
>
> +-X face (+-1,0,0,0,0)
>
> +-Y face (0,+-1,0,0,0)
>
> +-Z face (0,0,+-1,0,0)
>
> +-U face (0,0,0,+-1,0)
>
> +-V face (0,0,0,0,+-1)
>
>
>
> So we could make ctrl-click always move the selected face into the �V
> face for instance. The selected face and the implicit destination
> determine the 2 needed axes defining the rotation, allowing easy view
> rotations.
>
>
>
> Ok, so what is the big deal then? Note that all stickers of a face
> share the same face offset, so for a given 4-face, the sticker
> components we are working with during a twist are the zero
> components of the face ( e.g. for the +X face, it is only the y,z,u,v
> components of stickers that are changing when twisting) The problem
> is that for a 4-twist in MC5D, there is no good way to set the
> implicit part of the rotation because the 4 relevant component axes
> change from face to face. For the U and V faces, the projection does
> end up making certain stickers look like they are in the "center",
> which made made me first think we could define a twist by just making
> a sticker click move the clicked sticker to the "center". But for
> the X,Y, and Z faces, there is no "center" that is obvious to make the
> implicit part of the rotation. Hope this is making sense.
>
I follow the gist but don't fully grasp the details. I'm hoping that Don
will jump in here as he really has his head around this stuff.

>
>
> So my best thought at this point is that we define 4-twists with 2
> clicks. The first click picks a sticker. The second click picks
> where you want to put that sticker. The direction of the twist would
> just be determined by the order in which you clicked 2 stickers, so
> there would be no left/right clicking. Note that the 2 stickers
> selected have to be of the same type (just like in the 3D cube, where
> you can't twist an edge piece into a corner piece). It would be no
> problem to help with this visually, by only highlighting stickers that
> you can twist into after your first sticker is selected.
>
That makes good sense to me.

>
>
> I further propose for simplicity that we only allow 90 degree
> rotations (at least for now). This means we'll only allow clicking of
> "2-color" pieces to determine twists. This is somewhat limiting, but
> it does help avoid complexities.
>
This is exactly how we developed the first version of the 4D puzzle.

> I'm being lazy in that I don't want to tackle rotations in
> non-coordinate planes, so the 90 degree limitation is nice for that,
> but there are other issues too. For example, some corner pieces
> ("5-color pieces") would require multiple twists in different planes
> to move from one location on the face to the other. As an example,
> for the +V face, to move the sticker (1,1,1,1) to (-1,-1,-1,-1) would
> require twists to first alter two of the components, then a second set
> of twists to alter the other two components, since a rotation works in
> a plane and can only alter 2 components at a time (or 3 at most if the
> rotation axis is not aligned with coordinate planes). (Aside: This is
> related to the "orthogonal inertial rotations" discussion from last
> year and this example makes it easier to see how certain sets
> rotations have become commutative, not dependent on order, unlike
> rotations in 3-space). Anyway, extending the possible face twist
> rotations would be good future work.
>
>
>
> Does this sound like a good plan/suggestion?
>
>
>
> (1) 2 separate clicks determine a twist.
>
> (2) limit twists to 90 degree rotations (for now).
>
>
>
> Any better ideas for the interface?
>
>
>
> Charlie and I did talk some about this path this evening. One
> improvement he suggested was to make it easier to click the second
> sticker. For example, once the first sticker is highlighted, all
> possible 2nd stickers could immediately be highlighted, and maybe the
> closest one to the mouse at that point could even be marked
> differently and immediately selectable.
>
Sounds good to me. Perhaps the and/or key could activate
the immediately selectable twist. Perhaps the key could abort an
initial selection.

>
>
> As a final note on this topic, I thought it might be nice to provide
> an array of buttons and a face selection combo as well, so that the
> same behavior could be done without clicking if desired. It could
> actually be the same array of buttons Charlie is doing for the 5D view
> rotations. It would just be that if a face was also selected, the
> rotations only affected the one face instead of the whole puzzle,
> making it a twist.
>
I didn't quite follow that but here is what it made me think:
A rotation of an N dimensional face == a twist on an N+1
dimensional puzzle.
This seems especially elegant as it gives a blueprint for creating the
user interface for any number of dimensions. In the 5D case what this
means is that the user first selects one of the 4D faces and performs a
normal ctrl-click to rotate it exactly like we do in the 4D puzzle. That
face then rotates like they expect and also affects slices of its
neighboring faces. Neat. So how would they do the equivalent 5D
rotate-to-center? simply ctrl-shift-click on a non-central face. I.E. a
"super" control-click.

>
>
> *The Main To Do List:*
>
>
>
> I think there are 2 items left at a minimum to make this a puzzle
> people could start solving. First is to properly finish up the
> twisting. Second is to allow saving log files. Hopefully, this will
> be done in the next couple weeks and the race for the first 3^5 will
> be on. Don't know yet if I'll be compelled to join that or not ;)
>
You don't know? I sure do! ;-)
If I know you at all I think I know that you are really going to want to
grab that first solution. The only thing I wonder about is whether
anybody else will solve it after that but I suspect that one or two list
members will also need to do it even if they can't be the first. The one
thing I very much hope to avoid is having anyone solve it before you
have the saving of log files completely working. I'm still very sad that
Don's first 4D solution is lost forever.

>
>
> Of course there are plenty of other improvements that can make it
> nicer. Charlie and I want to release the source code for this like
> Melinda, Don, and Jay did for MC4D. I'd like to clean up my part of
> it first though :)
>
It's funny how much you and Charlie remind me of Don and myself. Perhaps
Jay or his doppleganger can help you with that clean-up! I'm really glad
that you guys have found each other. I hope you have as much fun as we
did. It's been one of proudest lifetime achievements.

>
>
> Sorry this email turned out to be long, and I hope it wasn't too
> laborious to read.
>
Not at all. There's never a lot of traffic on this list so there is
always plenty of time to digest meaty postings such as this one. Please
keep them coming.
-Melinda