Message #410

From: Roice Nelson <roice@gravitation3d.com>
Subject: Re: [MC4D] On Rendering the Elusive 8th "Face" of the 4D Puzzle
Date: Mon, 20 Aug 2007 12:31:48 -0500

I just had a couple minor comments.

First is that while I recognize this should be considered a matter of
personal preference (and my preference is therefore no better than
another’s), I find the "box with lid off" presentation undesirable because
it introduces an artificial manipulation of the projection. I imagine that
statement could be a source of contention depending on what one considers
artificial, but one is effectively taking apart the puzzle to present it in
this way. For a 3D being looking at a real puzzle, you’d never be able to
physically produce a Rubik’s cube that worked but had the out-face removed
and off to the side. For this reason, I wouldn’t want to see the projection
of the 4D puzzle done as such.

To me, there is not much difference between moving the lid off to the side
vs. doing a display somewhat like Alex presented (which would leave the lid
position true, but alter the projection and/or shrink parameters applied to
that single face so that the stickers did not obscure everything else).
Both solutions introduce unnatural effects into the result. To give a last
bit of further weight to my position, I’d like to point out the programming
model becomes less simple/elegant if one wants to introduce either of
these behaviors (I’m not saying it becomes too difficult, just less elegant
because of the special casing).

Another possible way to deal with this could be to implement the
shift-highlighting done in MC5D. If you press shift while hovering over a
cubie, all the stickers on that cubie become visible (whether the face is
set to be visible or not). The stickers are rendered with the current
projection settings regardless of where this places them in the view. This
would allow one to more easily probe the invisible 8th face without having
to move it into view. I can see this being considered an artificial
solution as well and so it is not ideal, but at least the projection would
remain true.

I do find that the MC4D/MC5D sight lines (eyepoint->lookat point) are
constrained to the coordinate axes limiting, and I’d like to extend MC5D on
this front at some point. The reason this hasn’t been too big of a thorn in
my side is that for doing solutions, the current setup is probably the most
desirable and what I would end up using anyway. It’d still be nice to have
extra this control over the projection to study the nature of the puzzle
though. In the case of MC5D, it’d be nice if the 4th and 5th dimensions
weren’t both centrally projected.
Finally, while I agree with David’s explanations of what is actually
happening with the outer face relative to the eyepoint, I don’t find the
description of it turning "inside out" offensive. To us, limited 3D beings,
that is what the stickers appear to do, even though they are not actually
turning inside out within the larger dimensional space. (In addition to the
handedness, if one side of a box lid was painted one color, and the other
side another, you would see the color of the lid change as your viewpoint
moved from the outside to the inside, so the issue of which side we are
viewing from is not necessarily meaningless - for the 120 cell program I
did, I actually allow one to control coloring of the different sides of the
cells and depending on the projection parameters, one can see the colors
change with viewpoint changes. It really does appear as if the cells are
turning inside out.) Anyway, talking about turning "inside out" seems as
fair as talking about sticker "distortions", both appearances only being due
to projection effects. I still think it was a nice point to make, and gives
a more subtle understanding of what is going on with the projections.

Sorry, my minor comments turned out more lengthy than I intended.

Take care all,

Roice

On 8/19/07, David Vanderschel <DvdS@austin.rr.com> wrote:
>
> On Friday, August 17, "Alexander Goldberg" <ajgold04@gmail.com<ajgold04%40gmail.com>>
> wrote:
> >For those of you who have also been curious where
> >those 8th "face" facets disappear to when they get
> >cycled outward(?), this post is open to your
> >thoughts. I hope some discussion of this subject
> >will be aroused here.
>
> Alex, you are not the first to raise this issue.
> Myself and others have raised it in the past and we
> got the same arguments against attempts to render the
> 8th face which you got from Melinda. I do not buy all
> those arguments. I say why below.
>
> Alex:
> >I’ve copied some discussions I had with Melinda on
> >the subject below, and am going to upload a couple of
> >renderings I made to depict how the 8th face’s facets
> >could be rendered to complete the image of the
> >hypercube.
>
> Melinda:
> >>There is currently no way to draw the 8th face.
>
> There may be no way that is currently implemented in
> the program, but there is absolutely no difficulty in
> rendering it. I refer to the hyperfaces as Left,
> Right, Front, Back, Up, Down, In, and Out. By this
> naming scheme, it is the Out face that the program is
> not drawing. The In face is the small, but
> undistorted one shown in the middle. (It is
> undistorted because all its points lie at the same
> distance from the eyepoint along the viewing
> direction - the axis on which the eyepoint lies.) The
> Out face, if drawn by the _same_ transformation, would
> render in the same manner as does the In face - just
> bigger, since it is closer to the eyepoint. (The eyepoint
> is on the In-Out axis.)
>
> >>We tried that before but the correct projection puts
> >>it inside the bounds of the rest of the puzzle rather
> >>than outside which just makes a mess.
>
> This is true. The hypercubies of the Out face project
> into the same 3D volume as do all the others and
> obscure one’s view of the other hyperfaces which
> project smaller.
>
> >>We don’t want to draw an unrealistic projection so
> >>it’s best to just not draw it.
>
> But there is an easy solution: Just shift the
> projection of the Out face over so that it does not
> fall on top of the others. This amounts to a
> presentation analogous to the "Box with the Lid Off"
> presentation of the 3D puzzle. That is the default
> configuration for presentation that I used in my
> implementation of the 3D puzzle, which you may try
> here: http://david-v.home.texas.net/MC3D/
> (The MC3D program can present the 3D puzzle in a
> surprisingly large variety of other manners, some of
> which are more useful for solving it. Actually, an
> even more compelling version of "Box with the Lid Off"
> configuration is the second one on the ConfigSelect
> menu.)
>
> >I’ve attached a couple of renderings of a quick 3d
> >model I made showing what the 8th face would look
> >like. Is this how you saw it? I’m not sure I
> >understand the realistic vs. unrealistic projection.
>
> Alex, I agree with Melinda that this is an
> ‘unrealistic’ projection. If you could show the
> mathematics of it, I might change my mind; but I
> cannot imagine a realistic projection from 4-space to
> 3-space that would produce this rendering. As far as
> I can tell, you have just plotted the stickers from
> the Out face in positions relative to the others which
> are suggestive of their geometric relationship in
> 4-space. In so doing, the face loses its integrity
> and its pieces are spread literally all over the
> place.
>
> >>I like your images and agree that it could make for
> >>a workable puzzle. What I mean by "realistic" is
> >>that there needs to be a natural projection from 4D
> >>into 3D of a 4D puzzle that includes face and
> >>sticker shrinks in 4D. In other words we do not
> >>allow ourselves to perform non-linear
> >>transformations on the 3D projections. Given that
> >>restriction, the outer face’s stickers would not end
> >>up outside the others but rather would be turned
> >>inside-out and would intersect other parts of the
> >>visible puzzle. It would just be a mess.
>
> The intersection problem can be solved easily by
> simply shifting the picture that results from the Out
> face over so that it no longer falls atop the
> renderings of the other faces.
>
> The "inside-out" issue is a non-issue. All the
> hyperfaces (which are 3D constructs) are flat in 4D.
> The issue is whether what we are seeing of one is the
> side which faces the center of the 4D cube or the side
> which faces outward. As it turns out, for each of the
> faces which is being drawn, the side seen is that
> which faces inward. The Out face, if drawn, would be
> as seen from the outside. For a 3D scene embedded in
> 4-space, the difference in its appearance depending on
> which side of the 3D hyperplane (in which the 3D scene
> is embedded) it is viewed from is that of mirror
> reflection. Aside from this switching of the
> handedness, there is no difference in appearance to a
> 3D observer whose eyepoint necessarily lies in the
> same 3D space into which the 4D scene is projected.
> The issue of "which side" we are viewing it from in 3D
> is meaningless, since our viewpoint lies _in_ the 3D
> hyperplane onto which the 4D scene has been projected.
> We see _everything_ in a manner which is "on edge"
> relative to the 4D scene. The viewer’s point of view
> is constrained to be in the same hyperplane as the
> projection, so the viewer is never on _either_ side as
> might be defined in 4-space.
>
> If what I was saying in the above paragraph is not
> clear, you might be able to gain some additional
> insight by playing around with the 1D rendering
> capabilities in MC3D. With MC3D you can approach the
> 3D puzzle from a 1D rendering as a Flatlander would
> have to. This is analogous to us 3D beings trying to
> approach the 4D puzzle based on a 2D rendering such as
> we get from MC4D. (MC4D must do a second
> projection to 2D to render the 3D scene which arises
> from the initial projection from 4-space. We think
> in terms of the 3D scene, but its rendering is 2D.)
>
> >>One could do something like what you depict but
> >>since it can’t be done within the constraints we’ve
> >>given ourselves, we aren’t likely to want to try to
> >>implement it.
>
> However, rendering the Out-face with a shift in
> 3-space is easily achieved. I would expect that the
> code which currently implements the rendering of the
> In face would work with very little modification for
> rendering the Out face. The trickiest part probably
> lies in determining when, during animation, the
> hyperplane of a face passes through the eyepoint,
> necessitating changing which image (shifted or not)
> the stickers in that face are plotted relative to.
> But nothing blows up. (E.g., no division by zero.)
>
> >>Notice also that right before a face becomes the
> >>invisible face it gets large and almost completely
> >>flat. It is actually turning inside out.
>
> This is not a correct explanation. What is actually
> happening is that the hyperplane containing the face
> is intersecting the eyepoint of the 4D-to-3D
> projection. When the eyepoint is _in_ the hyperplane
> of the face, the rendering of that face does go flat.
> The non-flat renderings just before and after the
> crossing differ by which side in 4D the face is viewed
> from and thus bear a mirror image relationship. So it
> is _not_ "actually turning inside out" - the 4D side
> from which we are viewing it is flipping. Nothing is
> turning inside out.
>
> You can see the analogous phenomenon in my 3D program.
> When you twist one of the laterally facing slices (not
> the Up or Down one), some of the stickers will move
> out of the plane of the Up face (the removed lid) and
> some will move into it. For a given sticker during
> the animation, the switch occurs when the plane of the
> sticker passes through the eyepoint of the projection
> from 3-space. At that instant, the sticker projects
> to a line segment. It is also at this instant that
> the program moves the presentation of the sticker from
> being plotted relative to one of the virtual centers
> to the other. You can study this effect in detail by
> using the mouse to control the animation, slowing or
> stopping it at the critical instant. (There are other
> configurations of the program in which as many as
> three of the faces are seen from the outside rather
> than the single Up face as in the default
> configuration, which presentation (without the shifted
> Up face) is analogous to that of MC4D. A variety of
> other presentation configuations arise in MC3D
> because, unlike MC4D, MC3D does not require the
> eyepoint for the first projection to lie on a
> coordinate axis.)
>
> I would very much like to see an option in MC4D to
> render the Out face in the manner analogous to "Box
> with the Lid Off" for the 3D puzzle. It seems to me
> that the code required to do this would be rather
> trivial compared to some of the impressive
> improvements Melinda has added recently. With respect
> to hyperstickers in the Out face, one’s ability to
> ‘see’ which set of hyperstickers lie on the same
> hypercubie is quite similar to the cognition required
> for the Box with the Lid Off presentation of the 3D
> puzzle. It’s just that, when one of them is in the
> Out face, a pair of hyperstickers stuck on the same
> hypercubie no longer appear to ‘face’ each other at
> close range. Instead, they both seem to be displaced
> in the same direction relative to the centers of their
> respective faces. It is easy to learn to see this
> relation with the default configuration for the MC3D
> program; and it would be easy to to transfer this
> learning to a version of MC4D which draws a displaced
> rendering of the Out face.
>
> I have attached a couple examples of roughly what it
> could look like. One is unscrambled and the other has
> a couple of twists from the unscrambled state. I
> mentioned that the In face is undistorted, but I was
> really talking about the more profound distortion
> which arises from the 4D-to-3D transformation. There
> should still be a little perspective distortion from
> the 3D viewing transformation and there is not enough
> of that in the Out faces as I have shown them. (I did
> it simply by blowing up the In face after rotating
> what had been the Out face into there, correcting
> for the mirror imaging.)
>
> Regards,
> David V.
>
>
>
>