Quickfur's renders

[Secret]

I'm not sure if this is a sclergel diagram but here's an illustration of what i want



The bottom view is what all your currently rendered objects looks like, with the anamost cell placed at the center of the 3D projection, hence being obsurbed the greatest in the projection image.

For the top view, the anamost cell is less obsurbed, while the katamost layer is the most obsurbed. (In 4D it is like as if the polar cell is 'stacked' on top of other cells like a series of circles stacked on top of each other to form an angled view of a sphere, where the curvatures are visible as circular curves)

The weird idea(Which is quite similar to what your idea is from the recent post)) illustrated here is (I believe) applicable only to polychrons that can be separated into north and south polar regions

But I'm not sure whether it will work.

[quickfur]

OK I see what you mean. I don't think I can do that easily, because currently the projection is done from 4D->3D, and then POVRay is used to render the 3D scene. In order to achieve what you describe, I'd have to hack the 3D scene so that the nearest cell to the 3D viewpoint gets moved towards the camera in front of everything else. Besides being hard to do, I'm not sure how much that will actually help in visualizing 4D, 'cos you lose the relationship between the nearest cell and its surroundings.

[quickfur]

So I've been pretty much rendering a polytope a month, like the Polytope of the Month project that I envisioned but never officially launched. This month's polytope is the rectified 120-cell:



This image shows the tetrahedra that lie on the near side (there are 600 tetrahedra in total, but only a subset are visible here). I like this render 'cos it looks like some delicate art piece made of colored glass.

But this belies the absolutely adorable puffy look of its 120 icosidodecahedral cells, for example:



Don't you just wanna reach into 4D and give it a big hug?

Anyway. More details can be found at the rectified 120-cell page.

[anderscolingustafson]

Pretty cool quickfur! These polytopes make me kind of wish that I lived in 4d so I could get an even better look at them.

[quickfur]

Today I made the Coolest Animation Ever:



This is the runcinated 120-cell rotating on one of its great circles. Only dodecahedra are shown. The yellow cells are on the near side of the polytope, and the cyan cells are on the far side. You can see them transition from yellow to cyan (and vice versa) as they rotate, turning inside-out in the process. You can also see the ring of cyan cells that lie on the stationary plane of the rotation - this is the "polar ring", if you will.

Since the runcinated 120-cell is just the 120-cell with its cells "exploded" apart (and the gaps filled in by tetrahedra and prisms), this animation can also be interpreted as the 120-cell rotating along one of its great circles (with its cells exploded apart so they are easier to locate visually).

Now I'm convinced that the next chapter on rotation in my 4D visualization document will take the 120-cell (and its family) as the primary object of study.

[quickfur]

Hmm, I appear to have missed last month's update:



which is the cantellated tesseract.

But no matter, this month we have a way cooler polytope, the cantellated 24-cell:



Now, isn't that a lot cooler? This beauty has 24 rhombicuboctahedral cells, 24 cuboctahedra, and 96 triangular prisms. Now, isn't that a mouthful? So many "cubocta"-whatevers. I should just use the geotome terminology: this polytope is the 1,0,1,0-xylotome, whose facets are 24 1,0,1-geotomes, 24 0,1,0-geotomes, and 96 triangular prisms (hmm, did we ever decide on -tome terminology for prisms?).

This forum has been so quiet I wonder if anyone still reads these posts. Sigh...

[Secret]

This forum has been so quiet I wonder if anyone still reads these posts. Sigh...

I'm always on
I 've also sent you two notifications in a row
Yet you failed to noticed during these days you were on
Just like most people I met on the internet
I'm as if does not exist to them
Most threads that where I last post
Ususally render dead for at least a day
I've no idea why

[quickfur]

Actually I did get your messages, but I didn't have anything useful to add to that discussion that you were referring to.

[quickfur]

Alright, all ye sleeping, dormant, and/or absent forumites: here's a treat for ya:



I don't think I need to explain what these are. They ain't no 4D objects, but they do occur as cells in 4D objects, so there! Click on the image for a full-resolution version.

Have at it!

[Secret]

@above
The do look good, though I 'm not really interested in the truncates etc.
I'm more interested on the regular shapes, cause they look more fundemental

===============================
Can you render a grided with one cube highlighted, hidden surface removed 3 sphere and an animation of it rotating along a fliping axis?

[Hugh]

I've enjoyed looking at your renders over the years Quickfur! Thanks for sharing your work here.

Looking at your latest 3D assortment pic, I find it fascinating to look at each one and see how the triangles, squares, hexagons etc all fit together so beautifully and evenly to form the 3D shapes.

Seeing your 4D renders though boggles my mind... I can't fully appreciate them but I can imagine how amazing they must be if they are made up of cells of the above 3D shapes fitting so beautifully and evenly together in a higher dimension of space!

[quickfur]

@above
The do look good, though I 'm not really interested in the truncates etc.
I'm more interested on the regular shapes, cause they look more fundemental

Ah, but they are so rare! Only 5 in 3D, 6 in 4D, and 3 in all higher dimensions.

===============================
Can you render a grided with one cube highlighted, hidden surface removed 3 sphere and an animation of it rotating along a fliping axis?

What's a "grided", and what's a hidden surface removed 3-sphere? So far I haven't yet figured out the best way to represent the 3-sphere in a 3D projection, because it is completely smooth and so the current method of rendering ridges only will just produce a 2-sphere, which doesn't help at all in understanding the 3-sphere. The best way I've found is still to examine the various uniform polychora and see how their cells are laid out, because they are all tilings of the 3-sphere.

The problem is analogous to the 3D case: how would you represent a "hidden surface removed" sphere in 2D? It just projects to a featureless circle. In fact, the only way we 3D beings know the difference between a flat circle and a sphere is that the sphere reflects light differently, for example, it has a specular highlight on it, so that the shading inside the circle is different. By indirect info like this, our brain interprets it as a spherical object rather than a flat one. (In fact, in the absence of adequate lighting, even we have trouble telling whether something is just a flat circle or a sphere. Unless we reach out and touch it and feel the curvature of its surface.) The problem with carrying this analogy to the 3-sphere is that we don't know how specular highlights are supposed to look like in 4D, so if I render the projection of a 3-sphere with a 3D specular highlight in it, that doesn't mean our brain will be able to interpret it in a 4D way and somehow "perceive" the "bulging" 3-manifold that is the surface of the 3-sphere. Of course, we can understand it by analogy, but that only works if we already know what the shape of the 3-sphere is like. And in the 4D case, we can't reach out and feel it so we can't tell if we're looking at a real 3-sphere, or just a regular "flat" 2-sphere embedded in 4D.

So really, in order for a projection of the 3-sphere to be useful, you need to somehow mark up its surface so that there are landmarks that you can use to judge the curvature of the surface. A completely featureless and smooth n-sphere just projects to a completely featureless and smooth (n-1)-sphere, which tells you nothing about what its "true shape" is. The uniform polytopes tile the 3-sphere, so their cells are, in a sense, "landmarks" placed on the 3-sphere that we can use to judge the shape of its surface. So for example, take an animation like this one:



If you follow the motion and shape of one of the colored cells, say the red one, then you see that it varies from being a cube, to a frustum, to a square, then turns inside-out into an inside-out frustum, then a smaller cube, then another inside-out frustum, then turns inside out again before returning to its original shape. Now the tesseract is a tiling of the 3-sphere (if we can just distort it a bit so that its cells are not flat, but bulge outwards to fit the curved surface of the 3-sphere), and the flatness of the red cube describes the angle of the 3-sphere's surface w.r.t. to our 4D viewpoint: the flatter the cube looks, the steeper the curvature of that part of the surface of the 3-sphere that it's lying on is. So notice how the cube is most like a cube (least distorted) at the center of the image. This means that the 3-sphere's surface is at right angles to our viewpoint around the central area of the projection image. As the red cube moves away from the central area, though, it starts to flatten -- that means that part of the 3-sphere's surface is now at a steeper angle from our viewpoint: it's curving away from us into the 4th direction. When the red cube becomes flattened into a square, that means that part of the 3-sphere's surface is now parallel to our viewpoint. When the cube turns inside out, that's when it has gone behind to the far side of the 3-sphere. The smaller cube is when it's directly on the opposite side of the 3-sphere. After that point, it starts rotating back out from the back side of the 3-sphere, but it doesn't reach the front side until it turns flat again --- that's when it has reached the opposite limb of the 3-sphere. After that point, it's back on the near side of the 3-sphere, still flattened because the surface at that point is still curving steeply away from us, then it comes back out to the front of the 3-sphere, where the surface is now more-or-less flat from our viewpoint --- that's when it returns to its cubical shape in the projection.

Find this confusing? I'm not surprised, because we don't have very much experience with 4D so our brain doesn't always automatically interpret it in that way. Also, the constant motion makes it hard for us to focus on any one aspect of the image, so it's not so easy to grasp. But what if we pick a 4D polytope that has more facets? Better yet, if those facets are identical to each other, so that we can compare their shapes to see how the curvature of the 3-sphere has distorted them relative to each other in the projection image? Bingo, we're now talking about projections of 4D regular polytopes. My favorite among them has to be the 120-cell:



As you can see, having 120 cells is making the polytope more-or-less a round shape, just like the 3-sphere. Much more like a 3-sphere than the tesseract, to be sure. Which means that it's a very good way for us to understand the shape of the 3-sphere. Especially since all of its facets are the same shape, which makes comparison very easy when we're studying how the surface of the 3-sphere distorts their appearance. Look, for example, at one of the 12 green dodecahedra surrounding the blue one. There are a few that you can easily pick out, and the edges are visible to help you locate them. Notice that they look more-or-less just like a regular dodecahedron, which means that that part of the surface of the 3-sphere is still relatively "flat" w.r.t. our 4D viewpoint. However, if you look carefully, you might notice that they're slightly flattened. That's a hint that the surface of the 3-sphere at that point, though still relatively "flat", is beginning to curve away from the 4D viewpoint. But if you look at one of the red cells, you see that it's quite flattened, though not completely flat. That means that the surface of the 3-sphere at that point is curving quite steeply away from our 4D viewpoint. And the closer we get to the surface of the projection, the flatter things look. That means that the curvature of the 3-sphere from our viewpoint reaches maximum steepness at the edge of the projection. Not only so; these 3 layers of steepness in curvature happens in every direction as you move away from the blue cell. This means that the surface of the 3-sphere is curving away from our 4D viewpoint in a uniform way, in all directions, as you move away from the blue cell--the curvature is changing in a spherical way. If the curvature only changes as you move in 2 of the 3 directions away from the projection image of the blue cell, that would mean that we're not looking at a 3-sphere, but at a spherical cylinder, whose surface curvature is constant in one direction, but curves in the other 2. If the curvature only changes in 1 direction, then it's not even a spherical cylinder; it's a cubinder, the surface of which only curves in 1 direction, and remains constant in the other 2.

Now you may complain that the 3-4 layers of cells in the projection image of the 120-cell isn't enough to really perceive the curvature of the 3-sphere---and I'd concede. That's like drawing 3 concentric circles and calling in a sphere: it's somewhat helpful if those circles are drawn at evenly spaced latitudes, 'cos then how their distance from each other apparently contracts in the projection image tells us how the surface of the sphere is curved. But having more latitude lines would help. And adding in some longitudinal lines would help even more. In fact, drawing some kind of regular grid on the surface of the 3-sphere helps the most. Hey wait a minute, that's just a tiling of the sphere! So we're back to polytopes (polyhedra in this case). So in 4D you have the 4D polytopes with lots of cells, which you can treat as "landmarks" drawn on the surface of a 3-sphere to help you visualize how the 3-sphere curves. The 120-cell family of uniform polytopes are good in this respect: they have lots and lots of cells that you can use as your "landmarks". Take this one, for example:



Whoa! that's a lot of cells. But this image is a bit too opaque, so we don't really see the insides of the projection. Ah, but that's why I render these things layer-by-layer, as you can see here: http://eusebeia.dyndns.org/4d/runci120cell.html. Look over those layers of cells, and see if you can notice how the slowly begin to flatten the closer they approach the "equator" (the limb of the projection), becoming completely flat at said equator.

Oh, and if you want an image that shows all layers at the same time (well, half the layers, the ones on the visible half of the 3-sphere), check out this one:



This one doesn't have quite that many cells, but at least the way those icosahedra flatten out as you move outwards in the image is very clear. That, my friend, is the curvature of the 3-sphere. (And this particular cutey is also the closest analogue of the 3D soccerball (aka truncated icosahedron). Its two types of cells are very close in volume, just like how the pentagons and hexagons in the soccerball are very close in area. If you apply the usual coloring scheme of black pentagons and white hexagons for the soccerball, then the 4D soccerball would have black icosahedra and white truncated tetrahedra -- so just imagine the image above is filled with white instead of green, and the different colors of icosahedra are all black. Yep, it's time for a game of 4D soccer!! (And yes, I call it a 4D soccerball because, like I said, these polytopes are tilings of the 3-sphere, so to understand the 3-sphere, a very good way is to study these polytopes.) And on that note, the 4D soccerball totally trumps the 3D soccerball, 'cos the 3D soccerball only has 12 black spots, but the 4D soccerball has 120.

[quickfur]

I've enjoyed looking at your renders over the years Quickfur! Thanks for sharing your work here.

Thanks for your encouragement! It's good to know I'm not talking to the wall.

Looking at your latest 3D assortment pic, I find it fascinating to look at each one and see how the triangles, squares, hexagons etc all fit together so beautifully and evenly to form the 3D shapes.

Seeing your 4D renders though boggles my mind... I can't fully appreciate them but I can imagine how amazing they must be if they are made up of cells of the above 3D shapes fitting so beautifully and evenly together in a higher dimension of space!

Yep, they're pretty amazing. And just very recently, I've finally successfully derived the face lattice of the grand daddy of them all: the omnitruncated 120-cell (aka the omnitruncated 600-cell). That little monster has 14400 vertices, 28800 edges, 17040 faces, and 2640 cells. Imagine if you will 120 great rhombicosidodecahedra folded up into a ball in 4D with 720 decagonal prisms wedged between them, ringed by 1200 hexagonal prisms and the remaining gaps filled in by 600 truncated octahedra. Pretty little thing, really, but a bear to handle programmatically due to the large number of elements. It took over 20 hours to fully enumerate its face lattice. Well, that, and my rendering program has a few places with rather lousy algorithms, so it just doesn't scale very well. For example, the face lattice computation *could* have benefitted from my AMD hexacore processor, but unfortunately it's not multithreaded so 5 cores were wasted. In any case, I've been finding that trying to generate these polytopes has improved my program in ways I'd never have imagined before, even if, had I really wanted to, I could've just downloaded precomputed coordinates off the 'Net somewhere. But then I'd lose the benefit of making actual improvements to my rendering program.

Anyway I'm starting to ramble. The real point was that now I have a way to compute coordinates for all the 4D uniform polytopes, so you'll be seeing lots more cool renders in future.

[Hugh]

That's amazing Quickfur!

How much on the cutting edge (literally as well as figuratively I guess lol) are you with this rendering program of yours?

Are you breaking new ground that no other program has done before elsewhere in the world?

When you say that you "could've just downloaded precomputed coordinates off the 'Net somewhere" does that mean that this has already been done in great detail by other programs and supercomputers?

[quickfur]

That's amazing Quickfur!

How much on the cutting edge (literally as well as figuratively I guess lol) are you with this rendering program of yours?

Are you breaking new ground that no other program has done before elsewhere in the world?

I don't know, actually. But as far as I'm aware, I'm the only one who combined the idea of perspective projection + hidden surface removal (culling) + rendering transparent ridges. The other programs that I'm aware of like Stella4D don't do full perspective projection (by that I mean you can't place your camera at an arbitrary point in 4D and project the polytope based on that; IIRC Stella4D only does projection on the surface of a cell). I don't blame them for not doing it either, since for projection-at-a-distance to make any sense at all, you need transparent ridges, but, as I'm finding out, even that in itself is not good enough. Due to the complexity of the 3D images, even transparent ridges fail to convey the full structure of the image after you have more than 2-3 layers of cells in your line-of-sight. So eventually you have to have a way of saying "highlight these groups of cells over here" or "highlight those cells over there with hexagonal faces" or "color these cells red and those cells blue", on a case-by-case basis. Which means that you need some kind of query language to refer to all these cells, and also a scripting language to be able to assign complex set of colors, visibilities, etc., in a maintainable way (i.e. you don't want to have to manually reassign colors to the same 600 cells every time you start a new session, or go back and recolor every 600 cells in 20 rendering setups just because you decided to color that one group of cells red instead of green---100% reproducibility is a big gain here).

Currently my program has a simple but quite expressive query language for you to address any element in a polytope based on their relative locations to the camera and to each other. (My opinion is that a query language that requires the user to enter 4D coordinates is too difficult to use, and besides, the whole point of the program is to help you learn 4D, not require prior knowledge of it.) Although I'm proud of having thought of the idea of a query language for polytopes, I'm not that proud of the current query language my program understands -- it is quite limited in many respects, and also inconsistent in some places. The scripting language is OK, but could've been designed better. It's also not as powerful in many respects as I would like; for example, it'd be nice if it had a built-in graph-coloring solver so that I don't have to manually 3-color an icosidodecahedron or 4-color a dodecahedron every single time I do a set of renders on a 120-cell family polytope, for example. (Yes there are things that are still not automated. At least it's better than it used to be. I used to have to manually discover the cell connectivity graph by using the limited query language to find neighbouring cells, and then draw out the graph on paper and manually assign colors to them, then copy the cell numbers back into the script... yeah, who knows what made me endure such an insanely boring task. Nowadays the program at least can automatically compute the connectivity graph of a selected set of polytope elements and output a graph definition that I can feed to a graph visualization tool like Graphviz, so that I can color the thing and then use a shell script hack to collect the cell numbers back together... ugh, there's still so much improvement to be done here.)

When you say that you "could've just downloaded precomputed coordinates off the 'Net somewhere" does that mean that this has already been done in great detail by other programs and supercomputers?

Well, the coordinates for these polytopes are either already known by the researchers who first discovered them, or can be computed by various means, such as by iteratively closing the polytope based on known values in its vertex figure. If I were lazy, I could've just used these existing resources to get the coordinates I needed.

However, being the stubborn perfectionist that I am, I was unhappy with these existing coordinates because (1) many sources of full coordinates (i.e. files containing the entire list of coordinates) were computed using low-precision floating point, so you'd get only about 6-10 digits of mantissa at the most --- very bad for Povray because Povray is very picky and if some polygons don't line up to within a tiny margin of error, it will either complain loudly or produce noticeable artifacts in the output. (2) Computing coordinates based on vertex figures suffers from the same problem, in that roundoff error accumulates after you've iterated a large number of times --- but with things like the 120-cell family polytopes, you can't help but iterate a large number of times, so you get rather poor quality coordinates from that. (3) Besides, such coordinatese have poor orientation -- some sets of coordinates that I've looked at have the polytope in some unknown, possibly random orientation, which is a pain to reorient manually so that the faces line up properly, say with the coordinate axes or at least have some kind of symmetrical orientation. (4) I don't know how much confidence one can have that the coordinates are accurate, because if you only have 6-10 digits of mantissa, plus accumulated roundoff errors if you use the vertex figure method, how sure are you that the coordinates are actually anything close to the real thing? Plus, if a particular computation turns out to not work because of roundoff error, you have no way of fixing the problem if your source coordinates were low-precision to begin with. (5) How do you know that the vertex figure coordinates you downloaded are accurate, if you don't know how it's derived, and it comes with only 6-10 digits of precision? What if you need a higher precision, then what?

So the only way of being sure about coordinates is either (1) store them in algebraic form, so that you can compute them to any precision you want for your needs, or (2) write algorithms for computing them, so that, at least in theory, if you needed higher precision you just compute more accurate starting coordinates and then run the algorithms again (and preferably the starting coordinates would have a known algebraic form that you can use to derive as many digits of precision as you need).

Also, recomputing these things from scratch also has the advantage of testing your knowledge: do you REALLY know these 4D polytopes enough to be able to compute their coordinates? If you write an algorithm and compute some coordinates, and then you find out that the coordinates produce some strange, irregular polytope with irregular facets, then, well, you've more to learn. But if you get expected results that match up with published data on the same polytope, then you can have the confidence that you have the proper understanding of it.

Another thing about recomputing these things is... finding nice coordinates that you can read without your eyes glazing over pages upon pages of seemingly arbitrarily-complex algebraic expressions. For example, the coordinates of the 120-cell that nowadays everybody uses was actually a late derivation, based on the discovery that the 600-cell can be derived from the snub 24-cell so that you have relatively nice-looking coordinates. The original 120-cell coordinates... well, I haven't seen them myself, but can you imagine? I mean, the coordinates we have now already look complicated enough, I'm not sure I want to see the original coordinates. Probably full of square roots sprinkled everywhere and filling up several pages with no discernible pattern to them. Well, OK, I'm not saying it isn't full of square roots everywhere now, but at least they have a very direct connection with the Golden Ratio, which we know is a staple of pentagonal things, instead of complicated 5-level-nested 25-term expressions that give you a headache just looking at them.

It was due to my stubbornness in not just giving in to downloading coordinates that I discovered a truly marvellous way of getting extremely nice coordinates for the hypercube truncates in any dimension, just by reading off the Coxeter-Dynkin symbol. It's so simple, in fact, that I can rattle off coordinates off the top of my head, just by looking at the CD diagram. I'm certain that coordinates for the hypercubic truncates were already known a long time ago, but, as far as I can tell, their direct connection with the CD diagram wasn't known, or at least was never published.

I also discovered a truly amazing pattern to the coordinates of the n-simplex, which is connected with the Greeks' triangular numbers of old. (Yeah, those Greeks were on to something, I tell ya!) It gives less-than-pleasant coordinates for the tetrahedron, but the tetrahedron is an exception in the sense that it just happens to be the alternation of the cube in 3D, but in N dimensions, this isn't true (including 2D, by the way). But not only so, I discovered a direct connection between the n-simplex truncates and the (n+1)-hypercubic truncates, and since the hypercubic truncates have coordinates that can be directly read off the CD symbol, I can also get the n-simplex truncates coordinates directly -- except in (n+1)-space instead of n-space. But using a particular kind of projection back into n dimensions, I found that it produces simplex truncate coordinates that have a very nice orientation (for example, they are all upright, instead of lying along some strange arbitrary line!) which also happens to have nice symmetries around each coordinate axis.

And just very recently, while trying to find a way to compute "nice" coordinates for the omnitruncated 120-cell (well, more like, trying to find an algorithm to compute it from the 120-cell that ensures uniformity), I kept getting irregular polytopes or coordinates that give the convex hull algorithm (which I didn't write, BTW, it's Komei Fukuda's cddlib code) such a hard time that it produced inconsistent results---until I discovered that the reason is related to how the ringed nodes in the CD diagram correspond with the face-expansion operation. Which then led me directly to understand just why calling the great rhombicuboctahedron the "truncated cuboctahedron" is a complete misnomer, and what the proper derivations are.

But anyways. I'm rambling again, but the point is that this is really more for my own learning than anything else; I could've chosen the easy way out but then I would've missed a lot of the insights that I picked up by attempting to solve the problem myself. I've learned all sorts of stuff along the way, such as some number theory, some interesting properties of algebraic numbers, field theory, group theory, graph theory, etc.. In fact, I've discovered (well, probably rediscovered) a way of manipulating a certain class of irrational numbers using only integer arithmetic and constant storage space per number (i.e., not a full-fledged expression tree). Even though most people would laugh at me for "wasting" my time reinventing the wheel (recomputing known coordinates), I think I got a lot more out of it than if I had chosen to just use what was already there.

And besides, I have this suspicion that some of the coordinates I have right now have never been computed before... recently I wrote a program that can recognize certain irrational numbers automatically, and I've discovered some interesting things about the coordinates of the 120-cell polytopes. I may (and I emphasize may---it's only a remote possibility) be the first one to have found closed algebraic forms of the coordinates for some of these polytopes. Armed with this combo of polytope dissector and irrational number recognizer, I've been able to get algebraic forms of coordinates where it would've been way too hard to compute by hand (and probably take way too long to compute in software like Matlab---with my approach, you compute the thing in floating-point and then turn it back into algebraic form, as opposed to manipulating algebraic forms directly which is very inefficient). In fact, with this number recognizer I can even take coordinates that only have 6 digits of precision and turn them back into their full algebraic form, and then recompute them with higher precision! It's like the ultimate antidote against roundoff error: I don't care about roundoff error because the number recognizer automatically "accuratizes" them after the fact. Buahahahaha.... oh, the irony... and I was the one who complained about existing coordinates being too inaccurate. Hahaha.

OK, I'll stop now. I talk too much.

[Hugh]

Whoa, what a response!

Thanks Quickfur for your work in helping others trying to understand 4D better... I visited your site and looked around, impressive!

Keep up the great work, it is great to watch as you uncover more and more, and help us as well.

[wendy]

All of the dynkin-coxeter diagrams are actually coordinate systems for the vertices.

For example, (a)---(b)-5-(c) = (a)---o--5--o + o----(b)-5--o + o----o--5-(c). The common group for vertices here is the pyritochoral set, of order 24. This is "even permutations, all changes of vertices", the default vertices are for icosa(, 1, f, 0), for icosadodeca (2,0,0), and (f2,1,f), and for dodeca (1,1,1) and (f2,0,1). You make the rest by adding these together as the simplex goes.

The trick for the group Nqr is to start with the dynkin graph, and make the canonical coordinates.

A1 A2 A3 A4 A5
o--4-o---o---o---o---o----o
1 r2 r2 r2 r2 r2 r2

The coordinate at coordinate for axis An is the sum of values of the marked nodes to the right of it, eg x4o3x4o, at the third axis, 1+r2. The vertices are then swapped by all permutations, all change of sign.

[quickfur]

All of the dynkin-coxeter diagrams are actually coordinate systems for the vertices.

Indeed! I have found this really neat way of computing coordinates using the CD diagrams: given a CD diagram with N nodes, first construct N sets of vectors, each set corresponding to one of the nodes. This is very easily obtained by selecting a well-known member of the family of polytopes generated by the CD diagram to be our reference, for example, for an icosahedral polyhedron, we can pick the icosahedron as our reference---since we already know the coordinates for it. So we compute 3 sets of vectors: the first set is the centroids of the icosahedron's faces, the second set is the centers of its edges, and the third set is its vertices. Now given any icosahedral CD diagram, say o5x3o, we start with a single point at the origin, then we see that the 2nd node is ringed, so we add each of the vectors from the 2nd set to the point to obtain the coordinates of o5x3o. Similarly, given x5x3x, we can start from any of the ringed nodes. Say we pick the first node. So we start with a point at the origin, then add to it each vector in the first set (the centroids of the icosahedron's faces), resulting in a dodecahedron. Then we look at the second set and add each vector to the surtope orthogonal to the vector. In this case, we find the edges are orthogonal to the vectors so we add the vectors to them (scaled such that the resulting polyhedron is uniform) to get the truncated dodecahedron. Finally, looking at the 3rd node, we add the 3rd set of vectors to the orthogonal surtopes---in this case they are the decagonal faces---and we get the great rhombicosidodecahedron. (Note that we can read the nodes in any order and still get the same results, e.g., start with the 2nd node to get the icosidodecahedron, then add the 3rd node (equiv. to expanding the pentagonal faces) to get the truncated icosahedron, then add the 1st node (equiv. to expanding the hexagonal faces) to get the great rhombicosidodecahedron.

In the 3D case this procedure may seem rather cumbersome, but in 4D it lets us construct the entire 120-cell family of uniform truncates with just the expand operator alone, plus it gives us a way to directly compute their coordinates. First we construct 4 sets of vectors: corresponding to the (centroids of) the vertices, edges, faces, and cells of the 600-cell. Then given any CD diagram from the 120-cell family, we expand the starting point using the vectors corresponding to the ringed nodes to obtain the resulting polytope. We can regard the ringed/unringed-ness of each node as a digit in a binary number, so we see that the uniform truncates are arranged in an n-cube with the starting corner as the degenerate "truncate" which is just a single point. Each ringing of the CD diagram is a vertex on this n-cube, and the order in which we read the diagram gives us a path from the starting vertex to the destination vertex. The 120-cell and 600-cell can be obtained in 1 step, for example, and so can the rectified 120-cell and the rectified 600-cell. Then the bitruncate, whose diagram is o5x3x3o, can be derived from either of the rectified polytopes just by expanding the other corresponding node (i.e., expand the pentagonal faces of the rectified 120-cell o5x3o3o, or expand 1200 edges of o5o3x3o --- those edges that are parallel to the edges of the 120-cell). IOW, the bitruncate is obtained in 2 steps. The the cantitruncates, runcitruncates, etc., can be obtained in 3 steps, and the omnitruncate in 4 steps. In each step, we can compute the coordinates directly: for each surtope orthogonal to the given vector, we just add the vector (suitably scaled) to the surtope's vertices. What is suitably scaled, though? That's easy: just scale it to the amount required for the resulting polytope to have the same edge length as the starting polytope (the other aspects of symmetry are already encoded in the vectors so we don't need to worry about them). To compute this, let F represent the surtope to be expanded by the vector, and let G be an adjacent surtope which shares a vector V with F. Denote by v(F) the vector to be added to F, and v(G) the vector to be added to G. Then the scaling factor h for each of the vectors is given by:

h = e / sqrt(2 - 2*v(F).v(G) / ||v(F)||*||v(G)||)

where v(F).v(G) denotes the dot product.

Using this method, we can directly compute coordinates for all the uniform truncates---"nice" coordinates too, if we select the suitable starting coordinates. Computing coordinates from vertex figures, etc., result in polytopes in irregular orientations; this method gives polytopes that have the same relative orientation with the starting coordinates, so if we choose the starting coordinates suitably, the result will also be similarly oriented. Orientation is important for rendering scenes, when we want to place things on surfaces, for example.

[wendy]

You can do this in three dimensions as well.

Alternately, you can generally avoid the scaling, to get unit edge, by simply adding the necessary vertices of a face together, eg

• vertex = vertex of {3,3,x}
• edge = vertex + vertex
• hedron = vertex + vertex + vertex
• face = 4 vertices / (phi for x=5, or sqrt 2 for x=4, 1 for x=3)

Works in any dimension, eg for {3,x}, 2f,0,0 = f,1,0 + f,-1,0 f=icosa.

[quickfur]

You can do this in three dimensions as well.

Yes, of course, it applies in any dimension, actually.

Alternately, you can generally avoid the scaling, to get unit edge, by simply adding the necessary vertices of a face together, eg

• vertex = vertex of {3,3,x}
• edge = vertex + vertex
• hedron = vertex + vertex + vertex
• face = 4 vertices / (phi for x=5, or sqrt 2 for x=4, 1 for x=3)

Works in any dimension, eg for {3,x}, 2f,0,0 = f,1,0 + f,-1,0 f=icosa.

Cool, thanks!

[quickfur]

There's been too much talk and too little eye-candy in the past few posts. Here's to remedy that:



This is the bitruncated 120-cell, aka bitruncated 600-cell. It's just the thing for soccer fans: it has a 120 soccer ball shaped facets, and is itself a big 4D ball! What more can you ask for?

And I've also updated my site so that all currently-posted polytopes have coordinates now. Yes, that's right! Full Cartesian coordinates in algebraic form for all of these little monsters, and all nicely factored in terms of Wendy's apacs and epacs operators! That is to say, these are not just mindless data dumps; they are factored into permutation sets and sign changes, and they are in algebraic form. Which means that 20 years down the road when coordinates with only 6-7 digits of accuracy become so laughably inaccurate as to be completely worthless, my coordinates will still be relevant. You just extract as many digits of accuracy as you fancy from the algebraic expressions. And to top it off, the pentagonal polytopes' coordinates are all expressed in terms of that beautiful number (1+√5)/2, the Golden Ratio.

And no, I didn't do this by hand... I may be insane, but I'm not that masochistic. The bitruncated 120-cell, for example, has 22 sets of coordinates factored from its 3600 vertices. If you can go through 3600 vertices, sort through them, and manually derive the 22 permutation sets for them, and write them in algebraic form in terms of the Golden Ratio, then I truly salute you. Now try doing that for the omnitruncated 120-cell's 14400 vertices. (OK, so I haven't posted that one yet, but rest assured that I already have the coordinates for it, and it will be posted one day. Be prepared!!!)

How then did I do this, you ask? Well, I wrote this awesome new program that, given a set of vertices, automatically groups them into permutation sets and factors them in terms of Wendy's permutation operators. It also does sign-factoring, so that (1,2,3) and (1,2,-3) become (1,2,±3), and so on.

As for the algebraic forms, that's a trade secret. Nahhh, I'm kidding. That's done by my numerical value recognizer, which is built on my hypothesis that simple algebraic combinations of small algebraic numbers are sufficiently distinct that you can recognize them just by their first few digits. For the 4D pentagonal polytopes, 6-7 digits are more than enough to distinguish between all possible coordinate values. So given a polytope of known symmetry, you can easily tell from the first few digits of its coordinates what the algebraic form of the coordinates must be.

[Keiji]

I'd just like to point out a grammar error (near the end of the 120 Truncated Icosahedra section):

For clarity, we omit the cells we've seen previously. These cells have been flattened into decagons, because they are being viewed at from a 90°. In 4D they are perfectly uniform truncated icosahedra.

How about "being viewed from a 90° angle"?

[quickfur]

I'd just like to point out a grammar error (near the end of the 120 Truncated Icosahedra section):

For clarity, we omit the cells we've seen previously. These cells have been flattened into decagons, because they are being viewed at from a 90°. In 4D they are perfectly uniform truncated icosahedra.

How about "being viewed from a 90° angle"?

Yes, it's rather awkwardly phrased, isn't it? OK it's fixed now.

[quickfur]

Gah, apparently I used that same phrase in many other pages as well. Grrr... they should be all fixed now. Let me know if you spot any more occurrences of that error!

[quickfur]

Here's more eye-candy for y'alls. I've re-rendered my 600-cell projections so that instead of showing a truckload of edges that look like somebody's tangled hair, the projection envelope is rendered using highly-transparent ridges, with the cells of interest rendered in a more solid color. Here are some samples:





Don't you think this looks much better?

Edit: forgot to link to the 600-cell page.

[quickfur]

Here's a new render showing the various icosahedral polyhedra that are embedded in a 600-cell's edges:



These polyhedra represents horizontal edges in the 600-cell at various "latitudes" of the 3-sphere. First the red vertex in the center is the "north pole", then the icosahedron lies on the "arctic circle" of the 600-cell, followed by the dodecahedron in the "tropics", then the icosidodecahedron right on the equator. After that the layers repeat in reverse in the southern hemisphere: another dodecahedron in the southern tropics, then an icosahedron "southern arctic circle", then the south pole.

Interestingly enough, the 600-cell may be constructed by placing 4 icosidodecahedra in each of the 4 coordinate hyperplanes, adding a tesseract, and then taking the convex hull. It only has 8 vertices that lie outside of the coordinate hyperplanes. (Cf. the icosahedron, whose vertices all lie on one of the coordinate planes in 3D).

4 icosidodecahedra + 1 tesseract = 600-cell

[quickfur]

This month's polytope is the runcitruncated 5-cell:



Another sweet and simple member of the 5-cell family. They're always a nice, light dessert after a full main course of a 120-cell family polytope. Have at it!

[SharkRetriver]

Yay! A new polytope!
(I have this thing against n-simplexes tho, their faces are opposite their vertices, and I find that more irregular than the other polytopes, but then that's just me. Also, I still don't know all of the operators for 4d, such as runcination or cantitruncation.)

[quickfur]

Yay! A new polytope!
(I have this thing against n-simplexes tho, their faces are opposite their vertices, and I find that more irregular than the other polytopes, but then that's just me. Also, I still don't know all of the operators for 4d, such as runcination or cantitruncation.)

I call that property "odd", as opposed to "even" where facets of the same shape are opposite each other, as are vertices. Simplexes are the only odd regular polytopes beyond 2D (in 2D they are the odd polygons). The 24-cell is the only even self-dual regular polytope above 2D. This means the self-duality of the 24-cell is special; it's not because you're just flipping opposite vertex-facet pairs like you are with the simplexes (also the 3D n-gonal pyramids), it's something inherent in the 24-cell's symmetry.

And I don't know what runcination or cantitruncation means, either. I work directly with the Coxeter-Dynkin symbol, which actually makes a lot more sense. Check out this post of mine some time ago, that talks about this.

One thing interesting about the simplexes is that even though they are odd, their self-duality causes some of their uniform truncations to be even. In 3D, this doesn't produce anything new, because the tetrahedron happens to be the same as the alternated cube, so the even uniform truncations actually coincide with the cubic truncates (specifically, the octahedron, the cuboctahedron (runcincated tetrahedron), and the truncated octahedron (omnitruncated tetrahedron)). In 4D, however, the 5-cell does not directly relate to the tesseract, so this produces 3 interesting truncates that are even: the bitruncated 5-cell (bounded by 10 truncated tetrahedra), the runcinated 5-cell (10 tetrahedra, 20 triangular prisms), and the omnitruncated 5-cell (10 truncated octahedra, 20 hexagonal prisms).

The 24-cell, of course, is already even, but its self-duality causes 3 of its truncates to have a higher degree of symmetry than the 24-cell itself. My favorite among them is the bitruncated 24-cell, bounded by 48 truncated cubes. I especially like it 'cos it's one of the first uniform polychora that I independently rediscovered, figured out the structure, and even drew a 2D projection diagram by hand, which I later confirmed by an actual projection. It is also one of the two facet-transitive uniform polytopes that aren't regular (the other being the bitruncated 5-cell, which is one of the even truncates of the 5-cell). Mathematically speaking, the bitruncated 24-cell directly relates to a special symmetrical mathematical object called F₄. Wendy calls it "octagonny" due to its relation with octagonal numbers, and I liked the name because it also reminds me of the 2D projection I drew for it, which consists of a lot of octagons and octagonal features.

[SharkRetriver]

I have finished my coordinate generator, which generates wireframes of polychora, and here's a sample.
Truth is, I'm not sure if it's a compound of 3 tesseracts or a compound of 3 16-cells.
Thnks to QF for coordinates