When I sat through years of high-school English spent mining Shakespeare for obscure sexual metaphors, I never thought I'd find myself saying this - so let it be recorded here for posterity:

I'm actually enjoying Creative Writing.

What gives?

• Creative Writing is active education, by contrast with the passive "I'm going to talk at you for a couple of hours, mmmkay?" model usually foisted on otherwise highly interested students.
• If you're one of the 2.5 or so stalwarts who have followed my blog through its previous incarnations here and here, you know that I wrote In Silico as part of NaNoWriMo. (If you didn't follow my blog back then: I made the 50k word mark, so there.)
• It's not programming. I mean, I love programming, but I already spend the majority of my waking hours on it.

Yesterday's Creative Writing class consisted of our first poetry workshop session, wherein we read and critiqued poems written by our fellow classmates. Critique is difficult to get right, and is not synonymous with criticism; good critique should point out obvious flaws, but it should also aid the recipient in identifying and building upon what works. Furthermore, the critique reflects the experience of the critic; it is hopefully not a stretch to suggest that one's capacity for precision and insight is directly correlated with said experience. This was made obvious by the remarks of comparatively more literate members of the class, who were able to identify linguistic shortcomings, appreciate highly effective devices, and suggest alternate interpretations with much greater ease than my poor CS-addled brain could ever hope to.

This advice could be applied equally well to the code review process. A bad review process is typically one-sided; the reviewer imposes their every preference on the hapless reviewee, who unquestioningly and silently does their master's bidding. A better review process is two-sided. The reviewee feels free to respond, to push back where they disagree; the review process becomes more conversational. The best review process, I'll argue, is many-sided - much like the workshop session in Creative Writing, it admits critique from all corners. More importantly, it allows reviewers to critique each other, to agree with common praises or misgivings, to debate contentious points. The reviewee is not left out of this process; rather, they are freely invited to defend choices made, much like the reviewee in the two-sided review. In short: the best review process is meta-critique.

Above: a cellular-based texture, Worley-style. Still implementing cool textures for my procedural content generation project; so far, I've got a couple of noise basis functions along with a framework for combining them into more complex textures. Next up: terrain generation. This will involve a few steps:

• Generate a heightmap. For a first pass rendering, midpoint displacement is dead easy to implement. Since heightmaps are textures, I can even slap this into my texture framework as another basis function (albeit one with a relatively heavy initialization time (although the midpoint values could be generated on demand!))
  
• Set up the OpenGL window. We've been using gtkmm for previous assignments; I see no reason to break that trend, as I can save time by slapping our old window setup code into the project.
• Issue OpenGL commands to render the heightmap. In its most basic form, this is just a series of GL_QUADS. If I was going after static rendering, I'd probably put the whole thing into a display list and use GL_QUAD_STRIPS instead; however, this will be interactive, so I'll need to do something smarter than shoving the whole terrain patch into a display list.

There are other considerations as well. For example, I might want to dynamically load blocks of terrain as the user walks around. Randomly generated terrain becomes a bit of a problem in this case - unless the blocks are "aware" of each other, there will be discontinuous jumps! I'll leave those problems for later.

22 days to go, and I'm putting the finishing touches on my raytracer. Above: my sample image, which features implicit surfaces and adaptive anti-aliasing. (Technical details? Bounded Newton-Raphson iterations, gradients for normal vectors. Simple. I'm told regula-falsi is preferred; if I had another day, I'd pop that in there. As for the adaptive anti-aliasing, I'm applying a Sobel operator to the luminance values from the first pass and randomly supersampling pixels above a certain threshold.) Unfortunately, the images seem to suffer from a good deal of noise; in raytracing, this is a sign of numerical instability. If I was pursuing a raytracer-based final project, I would investigate further and fix it, probably along these lines of attack: 

• The problem worsens with distance from the camera. This might be fixed by applying a projective transformation, but that would FUBAR angles for shadows and reflection.
  
• Some of the mesh models have wonky normals; it might be worth the time to recalculate them to the outside.
• I could probably eliminate a few spurious divisions and normalizations.

That said, I don't have time, so noisy images it is. Let's hope my final project is free of such trite errors!

I was watching Serial Experiments Lain when I noticed a certain LISP keyword scroll across the screen. A few posters have uploaded the still frame. Reminds me of the nmap cameo.

I'm now gearing up to tackle the implementation of this specification for an embedded microkernel in the infamous Real-Time Programming course at the University of Waterloo. To share the masochism, our team has started the PsychOS blog. We'll be posting about our exploits - favourable, frustrating, pants-less, or otherwise - there, so keep posted! I'll try to mirror particularly poignant posts here at Quizzical Quincunx as well.

In other news, I've solved We Are The Swarm from Facebook's Engineering Puzzles site. This one is pleasantly devious; out of respect for the puzzle-solving spirit, I'll refrain from posting any hints. Enjoy!