Far from the first and unlikely the last, I’ve taken a slight development detour.

Firstly, I have migrated this dev blog from WordPress hosted by my web host to this statically generated one hosted on GitHub.

I won’t bang on about it, but I was finding WordPress quite cumbersome and exceptionally slow—not just to load on the client side, but to do anything with it. It made the blogging process quite frustrating for me.

I’m now using gohugo.io and GitHub Actions to deploy, and it’s a much nicer experience. Not just for loading speed, but also on the authoring end. I’m writing these posts in Markdown in my IDE (VS Code) so I can easily move between development work and writing a blog post with minimal context switching.

This process wasn’t easy, but now it’s done I can forget about it.

Secondly, while working on the lighting and texturing pipelines in StaticRectangle, I came across an issue with my Transform class I hadn’t run into yet, but it was inevitable.

I was using some matrix math functions I had more or less copied from webgpufundamentals.com, and I came to a crossroads where I either continued with the pattern laid out there—which was great for initial steps and learning but lacking in some areas for longer-term project work—come up with something more fleshed out, or use a third-party library like gl-matrix.

I ended up with the latter. I’m not too concerned with dependencies as gl-matrix is lightweight, and I don’t believe I’ll gain much doing it myself; this math has been around a long time.

So I refactored my Transform class so that it’s now tracking orientations internally via quaternions and added convenience methods like Transform.lookAt so transforms can track a target.

In the future, I’d like to look at geometric algebra and rotors for orientations. I came across this video from Marc ten Bosch that I have on my watch list!

Here is a scene I set up to help debug the orientation issues I was having.

  • ~ opens the terminal
  • Mouse look with left/right mouse buttons
  • w, a, s, d to move
  • p to pause

In this scene, I have 100 axis transforms spherically distributed, all pointing towards a central cube that’s bobbing up and down.

With my previous Transform implementation I couldn’t easily aim a specific axis or even orient without gimbal lock issues.

Also, now that I have something a bit more substantial deployed, I can see something I need to look into. Specifically with asset loading: opening up the terminal, I can see that the axis and cube models take 152 ms and 117 ms, respectively, to load.

While this isn’t exactly a long time, these models are very small. The cube is 167 B and the axis is 5 KB, so I’ll need to do some profiling to try to track it down. I don’t have this issue locally, so I assume it’s something to do with file acquisition and not decompression. Not sure yet!