Week 4 Blog: Caught in the Matrix

Hi readers, welcome back to my blog!

Continuing from last week, I’m continuing to play around with CloudCompare to get my 4D model to work. Previously, I created a few animations for wireframes and block-face highlighting to have them ready to share week 5. However, I started off this week by discovering a few major problems.

Here’s what went down:

Development: I implemented multi-highlighting for the block-face model, applying different colors to each 3D cell.

Problem: Faces for blocks underneath other blocks would appear to show up in front or completely override blocks below.

Development: Last week, I hardcoded rotation along a single plane and called it a day. This week, I attempted to implement user controls and more complex operations.

Problem: Rotations were executed in the wrong order, causing confusing double rotations and wobbling. Additionally, lines were colored incorrectly, instantly flipping between red and blue when color modeling was applied. 

After talking to my external advisor about the issues I was experiencing, I unfortunately discovered that It was my math, not my code, that needed reworking. Think of a 3D fighter jet that can rotate in three directions. This jet can yaw, turn left and right, pitch, turn up and down, or roll around a central axis. It seems nicely matched: three angles for three dimensions, just like x, y, and z. However, these angles are actually better thought of as operations. 

Imagine a plane pitch down 45 degrees and then yaws 180 degrees. Following along with your arm, this would mean the plane is looking 45 degrees upward, and behind where it was. But if the plane turns 180 degrees first, then pitches 45 degrees, it will face down instead. Changing the yaw angle no longer represents the plane turning in its own left and right. Instead of spinning in a circle, it’s spinning in a cone.

Translating into my project, I started by animating the x-w rotation, which looks like a linear operation. With x, y, and z as the normal 3D coordinates, this x-w rotation should look like cutting a deck of cards. Rotating in 3D shouldn’t change the fact that the deck is flat. However, my original math turns this deck of cards into a weird, angular slinky.

I originally linked my 3D and 4D rotations together with one 4×4 matrix, using roll, pitch, yaw, plus three more angles. But now I know that I’ll have to unpack my rotation matrix so that 3D doesn’t compromise 4D. Since CloudCompare’s UI can handle 3D operations on its own, I just need to get 4D behaving how I want it to.

I’ve already done this week’s scheduled reading, learning how 4D objects project 3D and 2D “shadows”. With the knowledge gained, I might be able to optimize my layer-stacking model by hiding certain faces or simplifying complex 3D cells into a few flat surfaces and equations.

Fortunately, I still have one more day left this week to tackle my bucket list of fixes.

Wish me luck and see you all next week!