Week 3 Blog: A New Perspective

Hello readers, welcome back to my blog!

This week, I started by fixing the transparency for my layer model from last week. However, I quickly realized I was actually just configuring PyGame incorrectly! But I also learned that representing transparency with the Alpha value in RGBA is not the best way, regardless. The A value isn’t commutative with respect to drawing order, red over blue and blue over red yield different purples. It’s very common that multiple 3D cross sections of a 4D shape tend to occupy the same depth, so this causes one color to take priority depending on how the edges in my back end are sorted.

After discussing this with my external advisor, though, I’ve received a whole new perspective. The work done around 3D rendering already exists, so I also have the option to do w-layering in the 4th dimension instead of z-layering using depth. This way, the 3D shell of each cross-section can be generated and stacked on top of each other to create the same effect I’m aiming for. However, this still requires a robust definition for 4D shapes, with edges, faces, and cells. 

Here’s how that development went:

Development: I adapted edge-tracing logic to follow from the most negative w to the most positive. After storing the intersections and the polygons drawn between them in .ply files, I used CloudCompare to render them together.

Problem: Without prior familiarity with .ply files, I kept sending invalid polygons to storage because of redundant vertices. My backend indexing also caused other mishaps when translating over.

Solution: After reading up on .ply files, I was able to fix these issues and render shapes with CloudCompare

Development: To further familiarize myself with CloudCompare, I created the animations for block-face highlighting and wireframes with perspective.

Problem: My color-layering model is far too slow. Since shapes are defined by their 3D cross-sections, the edges of the 4D shape are jagged at low resolutions. However, it’s sending way too much information at the higher resolutions that mitigate this issue.

I could just let the simulation run for minutes per animation, but I still need to tune colors and transparency. I’ll need to properly think through what changing from z-layering to w-layering actually did. Additionally, I don’t think either is currently representing the model I’m aiming for accurately.

Perhaps my vision for this model will emerge with a bit of tuning. But for next week, I’m planning on fully fleshing out the control models, wireframes with perspective and block-face highlighting. My target for Week 5 is to have the animations for each model ready to share, so I’ll have to make these before optimizing my code.

For this week’s reading, I’ve read in depth on rotation in the 4th dimension, especially in relation to defining a quaternion’s angle in space. A vector in 3D has three angles for each pair of axes, xy, xz, and zy. But a 4D vector has six, emerging from the combinations of x, y, z, and w. Additionally, rotation in interactive spaces is often defined instead by roll, pitch, and yaw, based on heading instead of axes. After I’ve prepared my animations for Week 5, I’ll review this again to see how I can best represent these angles for intuitive interactivity.

For now, though, see you all next week!