daemonflower wrote:quickfur wrote:Don't forget that each of the surfaces of the original plus its copy and the prisms surrounding it will form a new (D+1)-face, and it is this face that will get extruded in the next iteration.

I'm still not sure we're on the same page here, because you talk about (D+1)-faces. When I say "surfaces", I mean actual 2D surfaces. I don't care about sur-cells of a dimension higher than 2. This is basically because I want to visualize the objects, and I do this in OpenGL, and OpenGL only knows how to draw surfaces, nothing else. *)

It is true that GL (or anything else for that matter!) can only render 2D surfaces, since the computer screen is only capable of displaying 2D surfaces! However, if you truly want to

visualize higher dimensional objects, it is really necessary to know which 2-faces belong to which surtopes/surcells. In the process of my own learning to visualize 4D objects, I discovered that it is most helpful if the visualization tool could, at the user's request, render the 2-faces belonging to a particular surcell (or particular set of surcells) differently so that its placement and orientation within the whole can be more accurately seen. Often, while contemplating these projections, one desires also to be able to tell the tool, "show me the surcells next to these ones (based on some specified criteria)". In order to do this meaningfully, the program needs to know which 2-faces belong to which surcells.

I figured, if I take every surface of the original object, and connect it to its extruded image with a new, rectangular surface, the surcell will generate itself. From your answer I'm still not sure if that is the case. I'll just try and see. That won't happen before the weekend, though.

I'm not sure what you mean by "the surcell will generate itself"; if you're hoping that the mere juxtaposition of 2-faces rendered by your program will magically make you see the surcells, you may be disappointed. To truly understand a higher-dimensional object, you really need to understand that it consists of bounding (n-1)-dimensional facets, and until you can fully grasp this, the object will not make very much sense: it will just generate an incomprehensible tangle of surfaces on the screen. The lower-dimensional surfaces are really merely incidental, and yield very little information about the true geometry of the polytope in its native space.

That is not to say that rendering merely 2-faces is of no help at all; since what else would we use otherwise? (Line-drawings, as I'm sure you're aware, are almost completely useless in visualizing these polytopes; past a certain point, they just start looking like somebody's hair on a bad hair day and give no useful insight at all.) The point is that you'll probably need to apply enhancements to these faces, such as highlighting faces belonging to a certain surcell, in order for the result to be informative. But in order to do this, you'll need to know what the surcells are: so the program needs to represent them, even if they cannot be directly rendered!

[...]As I'm only interested in rotopes right now, I thought these operations had a strict definition, as in

http://teamikaria.com/wiki/Rotope. Objects generated by cartesian products are beyond the scope of my program - extruding a polytope into a new dimension is quite different from taking the cartesian product of two polytopes. Let's stay with rotopes - as you can see, they give me headache enough.

Don't you worry; it takes a while before you can visualize extruded objects naturally, but once you do, it will seem almost trivial in retrospect.

Cartesian products took me a

long time to grasp... eventually, the most natural way of visualizing them (to me, at least) is to avoid approaching them from the standpoint of a Cartesian product at all, but to derive them geometrically from something simpler: in the case of the 4D Cartesian products, from examining the structure of the tesseract. In fact, when I finally grokked Cartesian products, it was almost by accident: I was contemplating the structure of the tesseract and comparing it to the extruded tetrahedron (the tetrahedral prism), and it occurred to me that it was possible to dissect the tesseract into two rings of 4 cells each. A little geometric imagination suggests varying the size of these rings by substitution with different polygonal prisms, and before I knew it (literally!) I was dealing with duoprisms, though at the time I didn't know they were duoprisms. In fact, I actually derived the duocylinder this way, as the limit of the duoprisms, without even realizing it was the duocylinder. It was after the fact that I went back to George Olshevsky's website and realized that these objects were actually the duoprisms he was talking about, and it was only after reading up a bit more about duocylinders that it occurred to me that it was the same object that I had re-discovered from a purely geometrical approach.

As a testament to the difficulty (at least to me) of approaching Cartesian products directly, it was only long after the fact that it occurred to me that the duocylinder is the Cartesian product of two circles, being the limit of the Cartesian product of polygons. This was after I had worked out many of its geometrical properties and made wireframe animations of it. I don't think I could possibly have derived any of this if I had only known it as the Cartesian product of two circles.

[...]I'd prefer to generate a circle in the way computer people always do - as a polygonal approximation. So, of course, I'm lying through my teeth if I say I want to do a spheration

I'd nitpick with your statement that computer people always generate circles as polygonal approximations---ray-tracing being the notable counter-example---but having created projections of the duocylinder myself using approximating duoprisms, I can fully sympathise with the utility of your approach.

What I'm having in mind is an operation analogous to extrusion - only that instead of one image the generating object is extruded to n images, all lying on a circle along the new axis. Far from mathematically correct, but works for me. **)

It's not far from mathematically correct at all. In fact, you've just derived the Cartesian product of a polytope with a circle, without knowing it as such.

Well, maybe not exactly, but if you start with, say, some polygon in the XY plane, and then "extrude" this polygon along a circle in WZ plane (note that a circle requires two dimensions to "circle" in, otherwise you could only get a line segment)---that is to say, take n copies of the polygon and place them along a circle in the WZ plane, forming a trace of them---then what you get is in fact equivalent to the Cartesian product of the polygon with a circle. If, instead of placing the images along a circular path, you place the images along a polygonal path, why, then, you've just made a duoprism! (See? They're not that hard to understand after all.)

Here one should be aware that whether the starting objects are hollow or solid will make a big difference. Strictly speaking, the Cartesian product of two circles is only the ridge of the duocylinder (the 2-manifold along which its two bounding tori are joined), which is isomorphic to the Clifford torus; the duocylinder itself is the Cartesian product of two discs.[...]

Which serves to strengthen my gut feeling that I should stay away from visualizing objects generated by the cartesian products - they are way more complicated to treat in a simulation.

Not really. You've almost stumbled upon them without even knowing what a Cartesian product looks like.

I think this just underscores the fact that trying to visualize a Cartesian product from a purely set-theoretic point of view (a Cartesian product is the set of all ordered tuples of the constituent sets) is almost impossible past 3 dimensions. However, approaching it from a geometrical viewpoint is much easier. If you're fairly comfortable with the structure of the tesseract, the following page may help you see that Cartesian products are really not to be afraid of:

http://eusebeia.dyndns.org/4d/duoprism.htmlBesides Cartesian products with round things (which generate other round shapes merely because of roundness of the starting object(s)), there is also the algebraic method of generating round shapes, using the rss() operator [...]

If I recall my rusty math correctly, what you're describing here is a way of defining a parametrized n-dimensional surface. That's something else I have on the shelf for my 4D viewer, but it will have to wait.

No, what this is, is to define a shape as the set of points satisfying a particular equation/inequality. It is not feasible to directly evaluate these equations/inequalities (although it does give us a nice, concise and precise way of expressing a certain class of shapes); rather, certain geometrical properties can be inferred from them by suitable application of algebra and analysis.

Or, to put it simply, they are for the math buffs to drool over, while those programmers among us would rather just deal with polytopic approximations of these things and leave it at that.

*) Well, technically, OpenGL can draw points and lines too, and even 3D textures, but that's beside the point here.

[...]

Well, OpenGL 3D textures are really only 2D

slices of 3D textures, since you can't directly render a 3D texture onto a 2D screen (and I doubt if GL can even project a 3D texture directly without a surface to slice it with).