Quickfur's renders

[quickfur]

In my polyview program, cells cannot be assigned a color, because they are not rendered directly. Only polygons can be assigned a color. Cells are highlighted by assigning their ridges (polygons) with a different texture than the surrounding textures. The program implements a simple query language that lets you easily select all ridges of a particular cell or set of cells, and lets you add to/subtract from the selected set. At the end, however, only one texture can be assigned to a polygon. So which polygon is assigned which texture depends on how the assignment set was chosen. Basically, later assignments will override earlier assignments. So if you polygon 123 is shared by cell 1 and cell 2, and you assigned texture 1 to the ridges in cell 1 and texture 2 to the ridges in cell 2, then polygon 123 will be assigned texture 2.

It is possible, as I implied, to select the ridges of a cell, and then remove certain ridges from the selected set before assigning a texture. Sometimes I do this for clarity. E.g., if the ridges of a cell that projects to a deeper layer in the 3D projection image, then assigning textures to ridges in cells that appear in a shallower layer may completely override the assignments to the deeper cell, so it becomes "invisible" in the result. One way to work around this is to select the ridges in the outer cells, then subtract the ridges in the deeper cell, so that the selected ridges include only ridges in the outer cells but not in the inner cell. Then the assignment can be performed without overriding previous assignment(s) to the ridges of the inner cell.

When cells are disjoint, such workarounds are unnecessary, so I usually just assign the ridges of a cell without subtracting anything. However, if a ridge belongs to a cell on the far side of the polytope, then sometimes it may still appear in the render, because the ridge happens to project to the limb. One way to work around this is to select all the cells of interest first, then subtract from that set the cells that lie on the far side, then select the ridges of the resulting subset of cells. In this case, the ridges that belong to far side cells will not be included in the set, so the texture assignment will not affect them. This generally produces better results in static images, so that you don't see "stray" polygons highlighted when they only belong to far-side cells. However, in animations this means that every time a far side cell rotates onto the limb, its ridges will suddenly "pop" into view, which can be jarring if you don't know what you're looking at. Similarly, every time a near side cell rotates out of view, its ridges will suddenly "pop" out of existence (they no longer get assigned the highlighted texture in that frame). This also produces rather jarring animations.

I have thought about having the texture gradually fade out as the cell approaches the limb, instead of a binary assigned or not state. The program currently doesn't support this, however, and because of the way the translation to POVRay input is done, some extensive, potentially disruptive changes will have to be implemented to make this possible. tl;dr: this currently isn't possible yet.

[mr_e_man]

At the end, however, only one texture can be assigned to a polygon. So which polygon is assigned which texture depends on how the assignment set was chosen. Basically, later assignments will override earlier assignments.

I see.

How hard would it be to change that, to combine two textures?
I'm not saying it ought to be changed, but it's a possibility.

In my polyview program, cells cannot be assigned a color, because they are not rendered directly.

Occasionally I've wondered about volumetric rendering, in the sense of making 2D images using information from everywhere in a volume, not just on surfaces.

The idea is that, as a ray of light passes through a transparent object, it gradually picks up the object's colour (or, more accurately, it gradually loses certain colours as the object absorbs them). The light's intensity is multiplied by exp(-kx), where x is the length of the light ray inside the object, and k depends on the material and the light's frequency (or colour). So, if you're looking at a 2D image of a 3D cylinder, it's almost completely transparent at the edges, and more opaque in the middle, because of the distances the light has to travel through the cylinder's volume.

But that's considering only transmission and absorption.

There are essentially five different things that can happen to a ray of light when it hits an object, as shown in the first image here: It can be reflected at the surface, or scattered at the surface, or absorbed, or transmitted, or scattered internally.

Of course, in rendering polychora, we shouldn't care too much about realistic optics; we should care more about conveying geometric information.

[quickfur]

Volumetric rendering is something worth exploring, but runs the risk of being difficult to understand because cell boundaries may become non-obvious.

The idea behind visualizing 4D objects with 3D renderings is to exploit the human brain's ability to figure out 3D geometry, and use that to infer the 4th dimension. However, the brain doesn't get 3D models directly from the world around it; it has to go through our eyes, which only see in 2D. And the objects that our eyes are used to seeing are those with clearly-defined 2D boundaries, like spheres and boxes, surfaces, etc.. Truly 3D objects without clear 2D boundaries appear like clouds with fuzzy boundaries, and our eyes aren't especially good at figuring out their 3D geometries accurately. They just appear as amorphous blobs of unclear geometry.

In fact, even with the current 2D polygon renderings, many 4D shapes are already rather difficult to understand. In the early stages of polyview, I pursued the ideal of rendering only polygons, without edges or vertices. The result was easily understood only with very simple polychora (tesseract, 16-cell, etc.). Once you start getting into more complex polychora, it becomes almost impossible to tell where the cell boundaries are and what the shapes of the cells are. Because of this, I firstly tried the compromise of highlighting certain cells by rendering their polygons in a different color. This is where polyview's original polygon texturing code came from. But even with this, I found it difficult to parse more complex shapes. Eventually, I had to add edges back into the images, otherwise complex shapes like the 120-cell family polytopes were nearly impossible to parse visually.

I suspect that volumetric rendering would make it even harder to parse the images. Though with edges included, it may be workable; so it may be worth experimenting with.

Still, i'm not holding out much hope for it because our eyes are really not accustomed to parsing this kind of objects. The current transparent-polygon rendering is already rather difficult to parse; in most of the images on my website I've had to artificially change the opacity of cells, making it more opaque near the center of the projection and less opaque towards the limb, in order for the result to be clear. Using a single opacity value generally results in an object that you can't really tell the structure of except the outermost 2-3 cell layers. Using volumetric rendering presents an additional difficulty to our 2D-surface-centric eyes, so the results may not be much better than the current images, if any at all.

[mr_e_man]

Next Catalan?

Or, are we still interested in that 3:1 double-rotation?
I do think some non-octahedral cells and the 8 axial vertices would be helpful.

[Klitzing]

Next monthly?
--- rk