Actually seeing 4D

[pat]

I added a tet to the applet.

My initial thought on the rotating the projection was that you could accomplish the same thing with just the first mouse button. But, that's incorrect. You want to see things from other angles but still have the surfaces removed as from the original angle. I can understand that.

I didn't get to implementing that yet though. I'll move that to the third mouse button and make a slider for scaling.

[quickfur]

I added a tet to the applet.

Cool! I like it. Just like what I thought it would look like. :-)

My initial thought on the rotating the projection was that you could accomplish the same thing with just the first mouse button. But, that's incorrect. You want to see things from other angles but still have the surfaces removed as from the original angle. I can understand that.

I didn't get to implementing that yet though. I'll move that to the third mouse button and make a slider for scaling.

Ok, thanks. Are you planning to make the source code available sometime? I'd like to poke around and try out some ideas I have.

[pat]

I'm definitely a big my-code-is-your-code kinda guy. I just want to get it a bit more stabilized and a tiny bit more commented before I throw the source up there, too.

[pat]

Okay, I've changed the third mouse button to move just the displayed projection. I had it snap back as soon as you release the button though. Without that, it got too confusing to figure out how things moved when you again used the first mouse button.

I added a scroll bar on the side to allow one to scale the shape. This is now just scaling rather than moving closer to the object, so the clipping artifacts from before should be gone.

And, I included the source code in the JAR file and linked to the JAR file at the bottom of the page.

And, for ease of reference, it's here: http://www.nklein.com/products/hsr/

[quickfur]

Okay, I've changed the third mouse button to move just the displayed projection. I had it snap back as soon as you release the button though. Without that, it got too confusing to figure out how things moved when you again used the first mouse button.

Cool, that makes it easier to explore the projection. However, it also makes it apparent that the applet isn't doing quite what I thought it was. When I use the 3rd button to rotate the initial view, it seems that there's only a 2D square in the projection. Shouldn't it be a 3D cube? (Or is this a case of boundary conditions causing the other 4 vertices of the cube to be clipped?) Also, I noticed that some view angles appear to have concave 3D images. I thought all tetracube projections are convex? At first I thought it was doing 3D clipping instead of 4D clipping, but then I get a concave net of lines, so apparently it is doing 4D clipping, but not quite how I thought it works.

I added a scroll bar on the side to allow one to scale the shape. This is now just scaling rather than moving closer to the object, so the clipping artifacts from before should be gone.

Cool, that's much better.

And, I included the source code in the JAR file and linked to the JAR file at the bottom of the page. [...]

Cool. When I get the time, I'll take a look and find out why the output isn't quite what I thought it was. Thanks!

[pat]

The square in the initial projection is actually a cube... the only visible facet's vertexes are: < -1, ±1, ±1, ±1 > But, in the projection from 4-d down to 3-d, the points < -1, a, b, +1 > and < -1, a, b, -1 > are getting mapped to the same point in 3-d. I'm open to suggestions. I am using the point's 4-d coordinates: < x, y, z, w > where x is into the screen and doing the projection down to 3-d by just lopping off the w. Do you think I should do a sort of perspective truncation?

To go from 3-d to 2-d, I do: x' = y / x, and y' = z / x. Should I do something similar from 4-d to 3-d? Should I do: x' = x / w, y' = y / w, z' = z / w? and then go on to project from 3-d down to 2-d? Does that make any real geometric sense?

As for why they are not convex, these are not projections of 4-d polytopes. These are projections of *some* 3-d facets of a 4-d polytope. I don't expect them to be convex.

[quickfur]

The square in the initial projection is actually a cube... the only visible facet's vertexes are: < -1, ±1, ±1, ±1 > But, in the projection from 4-d down to 3-d, the points < -1, a, b, +1 > and < -1, a, b, -1 > are getting mapped to the same point in 3-d. I'm open to suggestions. I am using the point's 4-d coordinates: < x, y, z, w > where x is into the screen and doing the projection down to 3-d by just lopping off the w. Do you think I should do a sort of perspective truncation?

Ahhh I see, so essentially you're using a parallel projection then? I had perspective projection in mind, at least from 4D to 3D. But this is still a bit odd, because if only one facet (cell) is visible, and the vertices all lie on the same projected plane, that means our view angle must be looking at the facet edge-on. But if that's the case, I find it hard to understand how other facets aren't visible, since there would be at least 1 other facet perpendicular to this one that must lie in full view.

Another way to put this is, if a given facet of the tetracube is obscuring our view of all other facets, then it must lie on the 3D hyperplane orthogonal to our line-of-sight (or close to orthogonal). But if this is so, then the facet should be projected to an (almost) identical volume in the realmar retina. The only case I can see where you'd end up with coincident vertices is if the hyperplane the facet lies on is parallel to the line-of-sight. But in that case, it can't possibly obscure our view of every other facet, because there would be other facets attached to it that lie on hyperplanes at orthogonal angles to our line-of-sight. Of these, there must be at least 1 that isn't obscured by the first facet.

Or am I missing something here?

To go from 3-d to 2-d, I do: x' = y / x, and y' = z / x. Should I do something similar from 4-d to 3-d? Should I do: x' = x / w, y' = y / w, z' = z / w? and then go on to project from 3-d down to 2-d? Does that make any real geometric sense?

Well, to me, it seems that in projecting 4D to 3D, if we're talking about a realmar retina, some kind of perspective projection should take place. So, yes, I think that would make sense. The projection from 3D to 2D can be anything, really, since it's just a way for us poor 3D beings to see the full 3D retinal image. Perspective projection would make it easier to grasp, I think.

As for why they are not convex, these are not projections of 4-d polytopes. These are projections of *some* 3-d facets of a 4-d polytope. I don't expect them to be convex.

Right, but we picked these facets so that they happen to be the ones that lie along our line-of-sight. I don't see how this would lead to a concave set of facets, since in the analogous 3D case, there's no view angle from which a 3D cube would project onto a concave area. (Or am I carrying dimensional analogy too far?)

When I get home, I'll have a shot at coding what I think should happen, and see if I can discover why the output seems to be inconsistent with what I expected it to be.

[pat]

Ahhh I see, so essentially you're using a parallel projection then? I had perspective projection in mind, at least from 4D to 3D. But this is still a bit odd, because if only one facet (cell) is visible, and the vertices all lie on the same projected plane, that means our view angle must be looking at the facet edge-on.

No. When you look at a 3-D cube such that you only see one facet, you are not looking at the facet edge one. Yet, you are seeing all of the vertexes in the same plane.

Another way to put this is, if a given facet of the tetracube is obscuring our view of all other facets, then it must lie on the 3D hyperplane orthogonal to our line-of-sight (or close to orthogonal). But if this is so, then the facet should be projected to an (almost) identical volume in the realmar retina.

And, it's just the way that I projected it that is keeping it from being that way. But, the problem is that I cannot see any geometrically consistent way to do otherwise.

Take for example viewing a square in Flatland and that the square really just sticks through Flatland, but you want to project it down to Flatland. If two sides of the square are perpendicular to your plane and your line of sight goes through the center of the square, then two points will get projected down to your plane to the same point... and the other two points will get projected down to another point.

One possibility that I was considering was to make your eyes slightly offset in the +/- w directions rather than in the +/- y directions. Then, the stereo image would be reflect w-depth whilst each image would reflect x-depth.

As for why they are not convex, these are not projections of 4-d polytopes. These are projections of *some* 3-d facets of a 4-d polytope. I don't expect them to be convex.

Right, but we picked these facets so that they happen to be the ones that lie along our line-of-sight. I don't see how this would lead to a concave set of facets, since in the analogous 3D case, there's no view angle from which a 3D cube would project onto a concave area. (Or am I carrying dimensional analogy too far?)

We picked the facets to be the ones visible from a particular viewpoint. I'm not sure that's the same as the facets along a particular line of sight as I'm not sure what you mean by that.

The proper analogy here, I believe is more like this. Imagine that you're along the x-axis somewhere looking back at the origin. There's a cube at the origin. You are looking directly at one corner of the cube. You can see three faces of the cube. Now, imagine if you took a light off down the y-axis somewhere and pointed it at the cube. Further, imagine that only the three faces of the cube that you can see will project a shadow. Would you expect that shadow to be convex? I wouldn't. I would expect it to be concave.

[pat]

And, it's just the way that I projected it that is keeping it from being that way. But, the problem is that I cannot see any geometrically consistent way to do otherwise.

I could potentially toss out the x-coordinate and use the w-coordinate in its place. But, that seems to be throwing out the fact that we're looking in the x direction. Then again, maybe it's saying that the x-direction is perpendicular to our retina. That would make sense.

I'll give that a whirl.

[pat]

Okay, at the bottom of the page, I've got that sort of thing now. The page is: http://www.nklein.com/products/hsr.

Maybe I'll integrate both into the applet some time.

And, yes... for what it's worth, I would expect these projections to be convex. But, they also are more confusing to look at than I had expected. Hmm....

[quickfur]

[...]Take for example viewing a square in Flatland and that the square really just sticks through Flatland, but you want to project it down to Flatland. If two sides of the square are perpendicular to your plane and your line of sight goes through the center of the square, then two points will get projected down to your plane to the same point... and the other two points will get projected down to another point.

Ahhhh, I see where the misunderstanding lies now. You're basically projecting X-Y-Z-W into X-Y-Z by truncating the W coordinate, and then projecting X-Y-Z into X-Y by truncating the Z coordinate. Now I understand why the applet output looks the way it does. This wasn't quite what I had in mind.

[...]We picked the facets to be the ones visible from a particular viewpoint. I'm not sure that's the same as the facets along a particular line of sight as I'm not sure what you mean by that.

The proper analogy here, I believe is more like this. Imagine that you're along the x-axis somewhere looking back at the origin. There's a cube at the origin. You are looking directly at one corner of the cube. You can see three faces of the cube. Now, imagine if you took a light off down the y-axis somewhere and pointed it at the cube. Further, imagine that only the three faces of the cube that you can see will project a shadow. Would you expect that shadow to be convex? I wouldn't. I would expect it to be concave.

OK, now I get it. That makes sense, based on how you're doing the projection.

What I had in mind, however, is more like this. Let's begin with 3D first, and see if I can explain myself clearly before we proceed to 4D. Imagine some scene, centered at the origin O for simplicity, and a 3D viewer standing at some position P some distance away. He is looking from P towards the origin. In front of P is a rectangular plane perpendicular to the vector PO, precisely D units from P along the vector PO, onto which light from the 3D scene is projected. This rectangle is our model of the viewer's retina. Suppose there is a 3D cube sitting at the origin. Given any point Q on this cube, its image on the rectangle would be the intersection of the line PQ with the rectangle (we're doing a perspective projection). The set of all such intersections where Q is not obscured by anything forms the 2D retinal image. As the viewer moves around the scene, the position of this rectangular retina changes accordingly.

Now, the 4D case: there's a scene around the origin, and the 4D viewer is standing at some point P some distance away, looking toward the origin O. In front of P, lying on a hyperplane perpendicular to the line PO at some fixed distance D away, is a cube, which serves as the 3D retina of the viewer. Suppose there is a tetracube sitting at the origin. Given any point Q on the tetracube, the image of Q on the retina is the intersection of the line PQ with the cube. (This intersection is always a point because P is not co-realmar with the cubic retina.) The image of the tetracube on this retina is simply the image of all possible points Q which are not obscured along the line PQ by other points of the tetracube. The image that forms on the cube, if my analysis is correct, would necessarily be convex. Also, given any point on this cube, only one cell can be seen at a time, since any other points in the tetracube that projects to the same point would be obscured.

To render this 3D image into the 2D screen of the applet, then, I imagine taking this image as a 3D scene, and viewing it from some 2D viewpoint V, along the same lines as I described for the 3D projection. V does not have to be the same as P, and can be moved around without changing P. (This is what I had in mind about the use of the 3rd mouse button.)

Of course, this is using the raytracing model, but I think you get the idea. It's just a matter of translating this to vertex projection, and that would be what I had envisioned the applet would do. Obviously, you had different ideas about how the projection should be done, which explains why it didn't look as I thought it should.

[quickfur]

Okay, at the bottom of the page, I've got that sort of thing now. The page is: http://www.nklein.com/products/hsr.

Maybe I'll integrate both into the applet some time.

And, yes... for what it's worth, I would expect these projections to be convex. But, they also are more confusing to look at than I had expected. Hmm....

Cool, now this is what I had initially envisioned. It's not really that confusing, if you realize that it's just a convex arrangement of projected polytope cells. I think I sorta understand what happened now. You had the view angle along the X axis, but you also threw out W, which means the projection has collapsed sideways along the W axis which is perpendicular to X, the direction of view. So no wonder some projections looked flatter than what I thought they should be. Collapsing along X makes sense, 'cos you can only see one thing at a time along the eye-to-object line (which in this case would be the X axis, if I understood you right).

[pat]

Actually, what I had there was wrong... I was technically assuming that you were in one position for purposes of clipping and in another position altogether for display. The version that's there now (at the bottom of the page) is much better.

The version at the top of the page has the x-axis going into the screen, the y-axis going to the left, the z-axis going up, and the w-axis going the other way while clipping is done as if you were along the negative x-axis.

The version at the bottom of the page has the w-axis going into the screen, the y-axis going to the left, the z-axis going up, and the x-axis not displayed at all while clipping is done as if you were along the negative x-axis.

There are some slightly concave things going on here, but I feel like that is just an artifact cause by there being a single viewpoint rather than the view being a parallel projection. I think, if it were parallel projection, you would get to see a couple of more vertexes which would fill out the shape. Those extra vertexes appear when you rotate further, but don't show for small rotations in only one plane.

[quickfur]

Actually, what I had there was wrong... I was technically assuming that you were in one position for purposes of clipping and in another position altogether for display. The version that's there now (at the bottom of the page) is much better.

The version at the top of the page has the x-axis going into the screen, the y-axis going to the left, the z-axis going up, and the w-axis going the other way while clipping is done as if you were along the negative x-axis.

Right, no wonder it looked odd.

The version at the bottom of the page has the w-axis going into the screen, the y-axis going to the left, the z-axis going up, and the x-axis not displayed at all while clipping is done as if you were along the negative x-axis.

It looks much better now. Now it's behaving like I thought it should. :-)

There are some slightly concave things going on here, but I feel like that is just an artifact cause by there being a single viewpoint rather than the view being a parallel projection. I think, if it were parallel projection, you would get to see a couple of more vertexes which would fill out the shape. Those extra vertexes appear when you rotate further, but don't show for small rotations in only one plane.

Are there still concave things going on there? I didn't notice any. I did notice that some angles show very flat cells, which may seem to be concave unless you look closely. The way they behave is very much in line with what I reasoned should happen as cells come into view/move out of view as you rotate the object into the W axis.

Now I'm dying to see the 16-cell and the 24-cell. :-) I'll take a look at the code and see if I can add one of them myself. It shouldn't be too hard, I think, just a matter of specifying the right bounding hyperplanes.

[pat]

Well, adding new polytopes is a matter of adding the correct vertexes and the correct hyperplanes and making sure the code that checks for hyperplane intersection checks the right planes.

With the Cube and the Tet there were lots of shortcuts available. I've been wanting to add the cross-polytope (16-cell). With the code there already, it would be easy to get all of the hyperplanes and vertexes in for that one. But, the intersection code wouldn't suffice. But, if I write general enough intersection code for the 16-cell, adding other polytopes should be easy.

[quickfur]

Well, adding new polytopes is a matter of adding the correct vertexes and the correct hyperplanes and making sure the code that checks for hyperplane intersection checks the right planes.

Right. I think for the 24-cell I have a pretty good idea of what the vertices ought to be.

With the Cube and the Tet there were lots of shortcuts available. I've been wanting to add the cross-polytope (16-cell). With the code there already, it would be easy to get all of the hyperplanes and vertexes in for that one. But, the intersection code wouldn't suffice. But, if I write general enough intersection code for the 16-cell, adding other polytopes should be easy.

True. I was reminding myself of (hyper)plane intersection calculation methods last night, and it occurred to me that they are more-or-less the same for any polytope. I notice that you already have code for a general hyperplane class that supports one of the operations (above()) needed for the calculation. Now it's just a matter of having a general intersect method, right?

[pat]

Alright... I added the 16-cell. So, if you know the vertexes and hyperplanes of the 24-cell and how to tell which vertexes share an edge, then you should be able to swipe the intersecs() code from the CrossPolytope.

[quickfur]

Alright... I added the 16-cell. So, if you know the vertexes and hyperplanes of the 24-cell and how to tell which vertexes share an edge, then you should be able to swipe the intersecs() code from the CrossPolytope.

Weird, now odd clipping is happening. Did you change the projection code again? The previous version (at the bottom of the page) was right, but now the tetracube looks like it has too many cells visible at a time.

As far as the 24 cell goes, I know the vertices and the edges. For isEdge(), I thought of using the property that the dot product of the endpoints of all edges is 2. However, this is also true of other pairs of vertices that don't share an edge. The distance of all vertices from the origin are also identical (cool property I didn't realize before!), so i'm not sure how to tell them apart.

[pat]

No, I didn't change the clipping on the cube at all. For a short time, I changed the clipping on the Tet to be the same as I made for the 16-cell to verify that it worked as I expected. But, I never touched the cube code and I didn't change the view code.

I've not seen anything I didn't expect in the cube. If I am looking at a corner of the hypercube, I would expect to see four of the eight cells. I've never seen more than four cells at a time in the hypercube. And, most of the time, I'm seeing three. Everything that I've seen seems consistent with the number of cells one would expect to see per edge across all of the polytopes---I think.

Can you show me a screen shot... or describe very precisely what dragging you did that results in something you think weird.

[quickfur]

No, I didn't change the clipping on the cube at all. For a short time, I changed the clipping on the Tet to be the same as I made for the 16-cell to verify that it worked as I expected. But, I never touched the cube code and I didn't change the view code.

I've not seen anything I didn't expect in the cube. If I am looking at a corner of the hypercube, I would expect to see four of the eight cells. I've never seen more than four cells at a time in the hypercube. And, most of the time, I'm seeing three. Everything that I've seen seems consistent with the number of cells one would expect to see per edge across all of the polytopes---I think.

Can you show me a screen shot... or describe very precisely what dragging you did that results in something you think weird.

Actually, the initial (reset) view is already a bit weird. In the previous version, the initial view shows the square face of a cube, which you can tell is a cube by rotating it with the 1st or 3rd mouse buttons. But now, it shows 4 cubes instead, including the outer and inner cubes. The outer and inner cubes are opposite cells in the tetracube, so they can't be visible at the same time when you're looking at them face-on.

Now, I actually have a copy of the code for the previous version; diffing it shows several changes in View.draw(): the pov has changed from (0, -offset, 0, -dist) to (-dist, -offset, 0,0), and there are a couple of changes in the computation of p1, px1, p2, and px2. I haven't looked more closely yet to see how this is affecting the results, though.

[quickfur]

As far as the 24 cell goes, I know the vertices and the edges. For isEdge(), I thought of using the property that the dot product of the endpoints of all edges is 2. However, this is also true of other pairs of vertices that don't share an edge. The distance of all vertices from the origin are also identical (cool property I didn't realize before!), so i'm not sure how to tell them apart.

Actually, I figured it out. All I need to do is to check if the distance between two points is equal to the edge length. I believe this exactly corresponds with the 24-cell's edges.

[pat]

Now, I actually have a copy of the code for the previous version; diffing it shows several changes in View.draw(): the pov has changed from (0, -offset, 0, -dist) to (-dist, -offset, 0,0), and there are a couple of changes in the computation of p1, px1, p2, and px2. I haven't looked more closely yet to see how this is affecting the results, though.

Ahh, the change from ( 0, -offset, 0, -dist ) to ( -dist, -offset, 0, 0 ) is important. It should be the latter. If it's the former, then the clipping is happening from a different point of view than the display.

And, there was one point where I was not doing any sort of perspective with the w-coordinate. So, you were seeing an orthogonal projection of the cube. If that makes more sense, I can go back to that. But, I thought that the stereo-pair worked better with the perspective projection.

So, my comment that things weren't different.... we were comparing different versions. I was comparing my latest two versions. You were comparing my latest version with the third-most-recent version. The second-most-recent version was only three hours after my third-most-recent version. I thought I had snuck the second-most-recent one in before you had seen the third-most-recent. So, we were on different pages...

[pat]

Actually, the initial (reset) view is already a bit weird. In the previous version, the initial view shows the square face of a cube, which you can tell is a cube by rotating it with the 1st or 3rd mouse buttons. But now, it shows 4 cubes instead, including the outer and inner cubes.

Hmmm... it doesn't show 4 cubes for me. If I 'reset' and then use only the third mouse button (to rotate only the retina, not my position w.r.t. the hypercube), I only see one cube. In the initial view (before touching the mouse button), I see one cube in perspective.

[quickfur]

Actually, the initial (reset) view is already a bit weird. In the previous version, the initial view shows the square face of a cube, which you can tell is a cube by rotating it with the 1st or 3rd mouse buttons. But now, it shows 4 cubes instead, including the outer and inner cubes.

Hmmm... it doesn't show 4 cubes for me. If I 'reset' and then use only the third mouse button (to rotate only the retina, not my position w.r.t. the hypercube), I only see one cube. In the initial view (before touching the mouse button), I see one cube in perspective.

Weird. Are you sure your browser isn't caching the old version of the applet? I just tried restarting my browser, and I'm still seeing the 4 cubes in the initial view.

Anyway, I've added the 24-cell, but I can't seem to get the bounding hyperplanes right, 'cos intersects() always returns false. Do you have any idea what I'm doing wrong? I'm pretty sure the points I pass to the Plane4D constructor are correct. Here's my testing version of the applet. I added a checkbox to enable/disable clipping (hidden cell removal) so that I can tell whether the 24-cell projection is right. (It's rather hard to tell just by looking at the lines :-)) Currently, it's wrong. :-(

[pat]

I have flushed my browser cache and restarted the browser. And, I get the same results whether I run the applet in Safari or the java appletviewer.




And, when I rotate it (with the third mouse button), it's just a single cube.

[quickfur]

I have flushed my browser cache and restarted the browser. And, I get the same results whether I run the applet in Safari or the java appletviewer.
[...]
And, when I rotate it (with the third mouse button), it's just a single cube.

Ahh, you're right. With the third mouse button, it's OK. But when you rotate it with the 1st mouse button, it starts getting into odd configurations. Although, it just occurred to me that this might be because the viewpoint is on the positive X axis but the clipping is done w.r.t. to the negative X axis? (Or something like this) Because, I notice that, starting from the initial configuration and rotating it with the 1st mouse button, the "inner cube" is visible but the "outer cube" isn't. I believe it should be the other way round.

[quickfur]

Anyway, I've added the 24-cell, but I can't seem to get the bounding hyperplanes right, 'cos intersects() always returns false. Do you have any idea what I'm doing wrong? I'm pretty sure the points I pass to the Plane4D constructor are correct. Here's my testing version of the applet. I added a checkbox to enable/disable clipping (hidden cell removal) so that I can tell whether the 24-cell projection is right. (It's rather hard to tell just by looking at the lines :-)) Currently, it's wrong. :-(

Alright, I think I got it to work!! :-) Woohoo, 24-cell! The starting view is awesome, 6 octahedra joined together in cubic formation. You can see it at the same URL as before (may have to restart your browser to make sure it fetches the latest version of the applet).

The logic in the code seems a bit weird, but somehow the results look right. Is there any way to verify this?? Basically, I found that the problem is caused by the else clause in intersects(), which I had just copied from the cross polytope. Removing the else clause makes it work properly. I don't understand why that didn't cause any problems with the cross polytope, though.

[quickfur]

[...]Ahh, the change from ( 0, -offset, 0, -dist ) to ( -dist, -offset, 0, 0 ) is important. It should be the latter. If it's the former, then the clipping is happening from a different point of view than the display.

And, there was one point where I was not doing any sort of perspective with the w-coordinate. So, you were seeing an orthogonal projection of the cube. If that makes more sense, I can go back to that. But, I thought that the stereo-pair worked better with the perspective projection.

You're right, the stereo pair makes sense with stereo-pair view. The 4D projection did have perspective all along, though. :-) Now that I've got the 24-cell working, I'll take a look at your latest code and see if I can figure out what it's doing that makes the output look odd.

[pat]

Although, it just occurred to me that this might be because the viewpoint is on the positive X axis but the clipping is done w.r.t. to the negative X axis?

No, I think there's some confusion here. The X-axis doesn't at all figure into what's displayed except for clipping. The clipping is done from a point along the negative x-axis. But, then, the w, y, and z axises are used to display.

Because, I notice that, starting from the initial configuration and rotating it with the 1st mouse button, the "inner cube" is visible but the "outer cube" isn't.

I think you're misinterpreting what's going on there. If you rotate with the third mouse button, you'll see that what you're seeing is a cube. If you rotate with the first mouse button slightly so that you get two facets in view and then rotate with the third mouse button, you'll see that you've got two facets which share a face. Then, if you rotate another direction with the first mouse button until you've got three facets showing... when you switch to the third mouse button (which only rotates the retina, not the point of clipping), you'll see that what you've got is three cubes which all share an edge. Then, if you rotate with the first button until a vertex is just about in the center and then rotate with the second mouse button a tiny bit, then with the third mouse button you can verify that you're seeing four cubical facets which all share a vertex.

[quickfur]

[...]I think you're misinterpreting what's going on there. If you rotate with the third mouse button, you'll see that what you're seeing is a cube. If you rotate with the first mouse button slightly so that you get two facets in view and then rotate with the third mouse button, you'll see that you've got two facets which share a face. Then, if you rotate another direction with the first mouse button until you've got three facets showing... when you switch to the third mouse button (which only rotates the retina, not the point of clipping), you'll see that what you've got is three cubes which all share an edge. Then, if you rotate with the first button until a vertex is just about in the center and then rotate with the second mouse button a tiny bit, then with the third mouse button you can verify that you're seeing four cubical facets which all share a vertex.

Actually, you're right. I think I misinterpreted it because of the tumbling-cube ambiguity (the projected lines aren't at the 3D depth I thought they were). Moving things around with the 3rd mouse button helps to make it clear what exactly the projection is.

However, there seems to be some cases where you get a concave projection. It seems to me that this shouldn't happen. I think that's what threw me off at first. I'm not sure why this is so.