4D visualization document updated

[quickfur]

Just dropping a note to say that I've just added chapter 8 to the 4D visualization document. Let me know what you think. :-)

http://eusebeia.dyndns.org/~hsteoh/4d/vis/vis.html

[pat]

Looks good... the only comment that I have is that the animations might be a tiny bit clearer if the squares(/cubes) were shaded a bit... cross-hatched or something to give the idea that it's the whole square, not just the boundary of the square that is of interest.

Another interesting thing would be to animate some of the other ways you could scan through the interior.

On your square picture, you've got a square in the x-y plane moving in +/- z. You could also have a square in the x-z plane moving +/- y or a square in the y-z plane moving +/- x. I wouldn't recommend trying to put them all in the same animation, but showing all three would be cool.

It's even cooler for the 4-d case. You're showing a cube in the x-y-z space moving in +/- w. Showing some of the other scannings would be cool... and probably much more informative in conjunction with the animation that you've already got than either would be alone.

[pat]

In fact, assuming the x points east-south-east in your pictures and y points north and z points into the screen (north-east), the animation of a cube in the y-z-w space moving in +/- x would also show off the fact that cubes are really "flat" (degenerate) in 4-d. The cube will start at one frustum, move across until it flattens in the middle and start expanding into the frustum on the other side.

That moment of flat will be echo-ed in the 3-d case with one of the other scanning directions where the "square" will flatten to a line before expanding into the trapezoid at the other side.

[quickfur]

In fact, assuming the x points east-south-east in your pictures and y points north and z points into the screen (north-east), the animation of a cube in the y-z-w space moving in +/- x would also show off the fact that cubes are really "flat" (degenerate) in 4-d. The cube will start at one frustum, move across until it flattens in the middle and start expanding into the frustum on the other side.

That moment of flat will be echo-ed in the 3-d case with one of the other scanning directions where the "square" will flatten to a line before expanding into the trapezoid at the other side.

Hey, that's a very good idea! And it's a trivial change to make, too: the animations are script-generated, so all I need to do is to change the viewpoint. :-) I'll give it a shot and see if the results look much better.

Now, about the cross-hatch thing, I'll try my best, but these diagrams are done using XFig, so the results may or may not look very good.

[quickfur]

OK, I've updated the animations to have the sliding square/cube move from side to side rather than from front to back. I've also updated the text accordingly. The result looks much better. Thanks, pat! :-)

Unfortunately, I wasn't able to do the cross-hatch/area-fill idea. The crude system I built around my geometric calculator program treats edges separately and doesn't know how to make polygons out of them, which is necessary to make XFig do area fills. So I won't be able to do it until later (much later, as I'll be going away for a while after this week).

Eventually I will get around to it, though; I really want to get away from the line-drawing paradigm, which is woefully inadequate to represent all but the simplest of 4D shapes. I'm already running into clarity problems with the 24-cell projections, which I really want to put up before I leave, if possible.

[pat]

Actually, I was thinking having both the animations you have now and the ones you had before would be best... though it would involve more text...

I do love the ones you have now.... they're really cool.... and they don't just look like expanding/contracting cubes.

The cross-hatching can wait.... that's awesome though that you're using xfig/transfig to generate these. Bonus! It'll be tough to cross-hatch a cube in a decent way though with xfig... maybe I'll play with it sometime.

[quickfur]

Actually, I was thinking having both the animations you have now and the ones you had before would be best... though it would involve more text...

Yeah, I was thinking of showing all 4 possibilities. But I'm trying to use only a minimal number of animations per page, so that loading time is not prohibitive for low-bandwidth visitors. Maybe I'll make a subpage for the rest of the animations. Or revisit the topic later on.

I do love the ones you have now.... they're really cool.... and they don't just look like expanding/contracting cubes.

Yeah, they are less confusing to someone not used to seeing 4D projections.

The cross-hatching can wait.... that's awesome though that you're using xfig/transfig to generate these. Bonus! It'll be tough to cross-hatch a cube in a decent way though with xfig... maybe I'll play with it sometime.

Well, xfig does have a way of making cross-hatch fillings, or, if that looks bad, area fillings (with color, too). You can also assign different depths to polygons to control drawing order, so that a filled polygon partially obscured by another will come out right.

My main obstacle is that the script which generates the animation frames is working with isolated edges and doesn't know how to join them into face polygons, so there's no easy way to make it output the appropriate xfig object.

[quickfur]

Just a quick note to mention that I've added chapter 9 to the 4D visualization document. It talks about 4D rotation, and at the end, shows you a cube doing a Clifford rotation! :-) I hope you guys like it. Comments welcome.

[bo198214]

Thanks! Any comments on my pages? :wink: I'm kinda stuck on what the next chapter should cover... any suggestions?

Yes, I have a suggestion. In the chapter hidden surface removal, the pictures would be more clear if the 3d-behind-lines would be broken, so there would be only one brain-interpretation (only say Necker-cube). I would like to see: If one 4D-opaque object is 4D-before another object, then it cuts out the other object in the 3d-projection, like this.

[quickfur]

Thanks! Any comments on my pages? :wink: I'm kinda stuck on what the next chapter should cover... any suggestions?

Yes, I have a suggestion. In the chapter hidden surface removal, the pictures would be more clear if the 3d-behind-lines would be broken, so there would be only one brain-interpretation (only say Necker-cube). I would like to see: If one 4D-opaque object is 4D-before another object, then it cuts out the other object in the 3d-projection, like this.

Hmm. In that chapter, I only used convex objects as examples, so all of the figures should be correct. (Unless you're referring to another chapter?)

But you're right, I eventually need to do a chapter on how objects obscure each other. The nearer objects will "cut out" the image of the farther object like you said. The only problem is that the program I wrote for generating those figures isn't advanced enough (yet) to calculate these cut-outs. :-?

[bo198214]

Hmm. In that chapter, I only used convex objects as examples, so all of the figures should be correct. (Unless you're referring to another chapter?)

No, no, no, dont get me wrong. I think the figures are correct. But if you draw the edges of a 3d cube in cavalier perspective on a paper there are two ways you can interpret the drawing as 3d. (no time to make jpgs ... ) You can swap the back face to the front and vice versa (sometimes this effect is also used in pictures which you can interpret in two ways).
To force perception of only one interpretation, you draw the front lines over the back lines, meaning you draw a back line broken where the front line cross it. And this technique would also avoid double interpretation in your 4D pictures.

You can draw a Necker cube by drawing the first crossing forcing the one interpretation and drawing the second crossing forcing the other interpratation. So it looks paradox. Btw. how about a chapter about 4d Necker-Cube? :wink:

The only problem is that the program I wrote for generating those figures isn't advanced enough (yet) to calculate these cut-outs. :-?

Yes, unfortunately programming (and executing) this is very extensive, so also I hadnt done this in my 4D Building Blocks (though it is planned). By the way what are your mysterious scripts that generate the pictures?

I saw this adanaxis demo (a 4d first person shooter study). Unfortunately *this* doesnt run correctly on *my* computer. The author Andy Southgate also wrote the tesseract trainer and posted on this forum with nick southa. Perhaps he has to solve the same problem. But he doesnt seem to look at this forum regularly. Would only be nice not to do the work trice ...

[quickfur]

Hmm. In that chapter, I only used convex objects as examples, so all of the figures should be correct. (Unless you're referring to another chapter?)

No, no, no, dont get me wrong. I think the figures are correct. But if you draw the edges of a 3d cube in cavalier perspective on a paper there are two ways you can interpret the drawing as 3d. (no time to make jpgs ... ) You can swap the back face to the front and vice versa (sometimes this effect is also used in pictures which you can interpret in two ways).

Ohhh I see what you mean. Yeah, you're right, the dotted lines would make it much clearer. Otherwise, it could be seen as the concave half of the cube. Hmph. Optical illusions...! :-) As if dealing with illusions with 4D rotations isn't bad enough....

To force perception of only one interpretation, you draw the front lines over the back lines, meaning you draw a back line broken where the front line cross it. And this technique would also avoid double interpretation in your 4D pictures.

Hmm, that's true. Unfortunately, if you add in the back edges as well, it makes for a rather messy tangle. It's not so bad for the 4-cube, but when you deal with things like the 24-cell, it's pretty illegible.

I actually installed PovRay recently and started playing around with it, in the hope that I can do plane-renditions instead of just edges. That would significantly help in the 3D perception of the images, and if I do it right, it may be possible to use the 2D equivalent of dotted lines for back faces so that we avoid the ambiguity you describe.

You can draw a Necker cube by drawing the first crossing forcing the one interpretation and drawing the second crossing forcing the other interpratation. So it looks paradox. Btw. how about a chapter about 4d Necker-Cube? :wink:

There's already one on the page :-) It's the first figure of the 4D cube, before any hidden surface removal is applied.

The only problem is that the program I wrote for generating those figures isn't advanced enough (yet) to calculate these cut-outs. :-?

Yes, unfortunately programming (and executing) this is very extensive, so also I hadnt done this in my 4D Building Blocks (though it is planned). By the way what are your mysterious scripts that generate the pictures?

I actually wrote a vector calculator program that can handle arbitrary-dimensional vectors, just so I can use it to test projections of higher-dimensional objects. :-) The current scripts I wrote for it generate the figures in XFig format (believe it or not), but it shouldn't be too hard to make it generate povray SDL files instead.

However, one BIG obstacle I'm facing right now is that for some of the diagrams I want to do, I need to implement a convex hull algorithm. That's rather messy to do in my (very limited and unfortunately poorly-designed) scripting language. I may have to re-write the program to have native ability to handle polytopes. Currently, it is a vector calculator and no more: it has tables, so the scripts use that to represent polytopes. But it's very memory inefficient and slow; I should probably move the core projection and polytope code into C++ and optimize it.

I saw this adanaxis demo (a 4d first person shooter study). Unfortunately *this* doesnt run correctly on *my* computer. The author Andy Southgate also wrote the tesseract trainer and posted on this forum with nick southa. Perhaps he has to solve the same problem. But he doesnt seem to look at this forum regularly. Would only be nice not to do the work trice ...

I never tried the shooter, even though I read about it when he posted it here. I think it may have something to do with the fact that it only runs on Windows...

[bo198214]

Hmm, i am not fully convinced that we talk always about the same thing :wink:
So I had to make some pictures despite.

I took your original image of the tesseract, then broke the lines according to their covering relation (as I would interpret it), and at last removed the 4d-hidden surfaces.

You have to admit that your picture

always looked a bit odd, because the back face seems to be concave and the blue inner vertex seems to be outside. And because you use perspective projection there is only one 3d interpretation possible (I think) and I would say you took the wrong 3d interpretation. Except this everything was correct.

Dotted lines are limited to distinguish only between totally back or totally front. The broken line technique is finer by showing which line covers the other, though its no magic bullet either.

[quickfur]

Hmm, i am not fully convinced that we talk always about the same thing :wink:
So I had to make some pictures despite.

I took your original image of the tesseract, then broke the lines according to their covering relation (as I would interpret it), and at last removed the 4d-hidden surfaces.

Eeek! No wonder we weren't talking about the same thing. Obviously, given your diagrams above, you didn't see the projection as it actually is. The cells are not a larger cube standing straight in front of a smaller, slightly higher, cube. The cells are actually distorted parallelopipeds laid out in two mutually-complementary tetrahedral arrangements. If you like, think of them as lying at the vertices of a stella octangula. (I know my interpretation is correct because I have the luxury of actually seeing this thing rotate in 3D, so that it removes all doubt of where the lines actually lie.)

The broken lines as you have shown above indicate that you incorrectly interpreted the projection as one having a larger cube standing on the ground in front of a smaller cube slightly lifted off the ground. This is unfortunately not the case.

But I'll grant you that the diagram is highly ambiguous... unfortunately, almost all such diagrams are highly ambiguous, because they lost 2 dimensions in the projection process and the foreshortening can be interpreted in more than one way. I tried my best to make the diagrams clear, but I guess I failed. :?

You have to admit that your picture

always looked a bit odd, because the back face seems to be concave and the blue inner vertex seems to be outside. And because you use perspective projection there is only one 3d interpretation possible (I think) and I would say you took the wrong 3d interpretation. Except this everything was correct.

Actually, there is more than one 3D interpretation. Where the blue lines meet, it is really inside the bounding rhombic dodecahedron. The back face that you're referring to actually isn't there; you took the wrong interpretation of the "Necker cube" for that cell. And I don't blame you; the cell is a parallelopiped, and when seen from this viewpoint, it is very natural for the mind to interpret the wrong way.

Unfortunately, I'm afraid I don't know how else to convey the correct projection other than to make a rotating version of the diagram, so I'll work on that and post it when I'm ready.

Dotted lines are limited to distinguish only between totally back or totally front. The broken line technique is finer by showing which line covers the other, though its no magic bullet either.

You're right. In fact, you underscored the problem I've been struggling with, and that is that wire diagrams are horribly inadequate for representing projections of 4D objects. There are so many things that can go wrong at every level. I seriously need to move all my diagrams over to use 2D surfaces via PovRay.

[quickfur]

Alright, I got the animation done. It's kinda big, but I wanted to put in extra frames just so there's no room for ambiguity. (Unfortunately, I'm expecting that it is still ambiguous...)



I think it should be clear that the cells are parallelopipeds (cubes squished between two opposite vertices, not along an axis). Note also that the 4D viewpoint is not exactly vertex-first, so the cells are not all deformed the same way. (This is also why the vertical blue line isn't really vertical, you can see it sway about a little as the thing rotates.) The important thing to keep in mind, just in case this diagram still isn't 100% unambiguous, is that the whole thing is rotating only in 3D, so you have to see a solid, unchanging 3D wire mesh rotating. If you see cubes that are deforming in 3D, then you're not seeing it correctly. (And it would not be your fault... like I said, these wireframe diagrams are horribly, horribly, ambiguous.)

What do you think? Maybe I should put this animation in that chapter so that it will clear things up? Unfortunately, I don't have a way to put dotted lines in the animation, 'cos I need to implement convex hull in order to automate it. Maybe I should just forget about XFig and rebuild everything from scratch with PovRay. (But even then, there's no guarantee the result will look right...)

[bo198214]

Ok, the perspective projection is only unambigous if one knows that it depicts a cube (as I assumed that there are 2 cubes in your picture).
Hmm, what regards the rotation ... I really have difficulties to see it rotating in 3d, sometimes the interpretation even swaps the rotation direction .

A parallel eye, or red/cyan picture would help a lot.
The only problem with these techniques is, that not anyone can benefit from it. Some people only can see crossed eye, some only parallel eye, some nothing of that, and some dont have read/cyan glasses.
And it becomes very cumbersome if you would provide four versions of every picture.

At least that way one would only loose 1 dimension.

Unfortunately, if you add in the back edges as well, it makes for a rather messy tangle. It's not so bad for the 4-cube, but when you deal with things like the 24-cell, it's pretty illegible.

Maybe its illegible only in the flat view, when you see it 3d it should not be that confusing. But I am anyway against 3d back face removing when viewing 4d shapes. I want to see the picture like a 4D being with only one eye (at least with that amount of information).

So when you use povray I beg you not to use opaque surfaces. There should be something usable like toned glass or so (as in the tesseract trainer). For convex hull I hope you read my article.

never tried the shooter, even though I read about it when he posted it here. I think it may have something to do with the fact that it only runs on Windows...

Never heard of "WINE"?
Though I tried it with windoze, but there seemed some problems with showing text, maybe font or so, so it was not usable...

But one question remains, you have a picture of a 4d necker-cube
Did you have a look at this article? A 3d necker cube can considered that way:

There are two interpretations of a transparent cube, the Necker-cube is a mixture. And now I want to see your 4D-Necker-cube!

[quickfur]

Ok, the perspective projection is only unambigous if one knows that it depicts a cube (as I assumed that there are 2 cubes in your picture).
Hmm, what regards the rotation ... I really have difficulties to see it rotating in 3d, sometimes the interpretation even swaps the rotation direction .

Sighhh... I knew the animation wouldn't be 100% unambiguous. I think the problem here is that you're expecting to see a 3D cube with 90-degree angles. But actually, the projected cubes are not cubes in the 3D image, but parallelopipeds. There are four cells present in the animation, and they meet at the central vertex where the blue lines meet.

But again, it's not your fault that you can't see it... wireframe diagrams are much too ambiguous. I wish I had a better way to convey what the image really is, but right now, I've run out of ideas.

A parallel eye, or red/cyan picture would help a lot.
The only problem with these techniques is, that not anyone can benefit from it. Some people only can see crossed eye, some only parallel eye, some nothing of that, and some dont have read/cyan glasses.
And it becomes very cumbersome if you would provide four versions of every picture.

I don't have red/cyan glasses. :-)

At least that way one would only loose 1 dimension.

Unfortunately, if you add in the back edges as well, it makes for a rather messy tangle. It's not so bad for the 4-cube, but when you deal with things like the 24-cell, it's pretty illegible.

Maybe its illegible only in the flat view, when you see it 3d it should not be that confusing. But I am anyway against 3d back face removing when viewing 4d shapes. I want to see the picture like a 4D being with only one eye (at least with that amount of information).

OK, I see that we're not on the same wavelength here. The image does have ALL 3D edges present!!! I fully agree with you that no 3D back faces should be removed: that would be like seeing everything only in silhouettes. The only back-face removal I did here is with respect to the 4D viewpoint, NOT the 3D viewpoint! There are no 3D edges being clipped.

I wish my scripts were a bit more sophisticated that they could automatically use dotted lines for edges that appear in the far sides of the 3D image, so that at least you have an idea of which edges are where. Unfortunately, I can't do that right now, so the lines are really very confusing.

OK, I'll try to explain what you should be seeing in the animation:
1) The (almost) vertical blue line is supposed to be the rotation axis, or at least, very, very close to the rotation axis. The image is rotating around this axis.

2) The point where the blue lines meet are at the CENTER of the 3D volume of the image, NOT on the outside, not in front or behind, but in the center.

3) ALL the black lines lie on the OUTSIDE of the 3D volume. They do not form regular cubes, but parallelopipeds (NONE of them make any 90-degree angles with each other... I know this is very confusing because our mind is used to thinking in terms of cubes, but you have to NOT make that assumption in order to understand this image).

Maybe you can check out the shape of the rhombic dodecahedron. Note how the rhombic faces appear to make cube shapes, but actually they are NOT cubes! In my animation, ALL of the black lines are the edges on the outside of a rhombic dodecahedron. NONE of them lie in the interior. There are only 4 edges that lie in the interior, and they are the 4 blue lines.

This is as clear as I can describe it. I don't know how else to convey it, except by figuring out how to make this animation in PovRay with appropriate texturing so that it removes the inherent ambiguity in the wireframe diagrams.

So when you use povray I beg you not to use opaque surfaces. There should be something usable like toned glass or so (as in the tesseract trainer). For convex hull I hope you read my article.

Oh, I ABSOLUTELY agree with you that there must be no opaque surfaces. That would totally defeat the purpose of projecting to 3D first, you might as well just project to 2D and be unable to reconstruct the 4D object.

I think the problem is that the wireframe diagrams are too ambiguous, so unless you know what you're looking at in the first place, your mind would probably interpret it the wrong way. Which is probably why I thought the images were OK: I was already expecting to see it a certain way, and so I wasn't aware of just how ambiguous the image really is, to somebody who doesn't know beforehand what it's supposed to look like.

never tried the shooter, even though I read about it when he posted it here. I think it may have something to do with the fact that it only runs on Windows...

Never heard of "WINE"?

Yes, I did, but for non-trivial apps, you need the .dll's from a real Windows installation, which I don't have.

Though I tried it with windoze, but there seemed some problems with showing text, maybe font or so, so it was not usable...

OK.

But one question remains, you have a picture of a 4d necker-cube
Did you have a look at this article? A 3d necker cube can considered that way:

There are two interpretations of a transparent cube, the Necker-cube is a mixture. And now I want to see your 4D-Necker-cube!

See, the problem is that my diagram actually isn't an impossible cube... the problem is that wireframes are too easy to misinterpret. I'll have to get cracking on doing a povray animation of this thing instead (or at least just a good static image). I'll post it when I'm ready.

[pat]

A bit of pedantics on definitions.... a Necker cube is just a wireframe drawing of a cube with the ambiguity left intact. Quickfur, what you're calling a necker cube is really an "Impossible Cube".

In your sequence of four drawings, you have (from left-to-right) a Necker cube, a cube, a cube, and an impossible cube.

What you're hoping for is an Impossible 4-D Cube, not a 4-D Necker Cube (as you've already got lots of those).

For reference:
http://mathworld.wolfram.com/NeckerCube.html
http://www.bbc.co.uk/science/humanbody/mind/surveys/neckercube/
http://en.wikipedia.org/wiki/Necker_cube

[quickfur]

A bit of pedantics on definitions.... a Necker cube is just a wireframe drawing of a cube with the ambiguity left intact. Quickfur, what you're calling a necker cube is really an "Impossible Cube".

In your sequence of four drawings, you have (from left-to-right) a Necker cube, a cube, a cube, and an impossible cube.

What you're hoping for is an Impossible 4-D Cube, not a 4-D Necker Cube (as you've already got lots of those).

OK, I was starting to wonder what exactly was being referred to by "Necker cube". :-)

Anyways, I've done a quick-n-dirty rendering of the diagram in PovRay, using a simple ball-n-sticks model. It's not perfect, since it's still only a wireframe of the actual projected image, but hopefully this will clear up the confusion about what is rotating where. The GIF file turns out to be MUCH bigger than I'd hope, but that's what you get for a higher-quality image, I guess.



Note that the thing is actually hovering slightly above the floor... I hope that won't lead to any confusion.

[pat]

What does the blue mean again?

[quickfur]

What does the blue mean again?

Just that it lies inside the 3D projection envelope. I guess it's redundant here, 'cos povray's lighting makes it clear that they are inside.

[bo198214]

Ok, now everything is clear (had really a misconception of what a necker cube is - learned by reading ...)
Thanks to quickfur for the nice povray image (though I trusted you in that anyway), its really unambigous :wink:

[Keiji]

What does the blue mean again?

Just that it lies inside the 3D projection envelope. I guess it's redundant here, 'cos povray's lighting makes it clear that they are inside.

Make that object no_shadow and it'll make it much clearer.

[quickfur]

What does the blue mean again?

Just that it lies inside the 3D projection envelope. I guess it's redundant here, 'cos povray's lighting makes it clear that they are inside.

Make that object no_shadow and it'll make it much clearer.

True... although then it loses part of the visual realism which helps to disambiguate the sometimes unexpected structure of the 4D projections. I'll give it a shot just to see how it turns out.