Python has a handy built-in function called enumerate(), which lets you iterate over an object (e.g. a list) and have access to both the index and the item in each iteration. You use it in a for loop, like this:

for i, thing in enumerate(listOfThings):
    print("The %dth thing is %s" % (i, thing))

Iterating over listOfThings directly would give you thing, but not i, and there are plenty of situations where you’d want both (looking up the index in another data structure, progress reports, error messages, generating output filenames, etc).

C++ range-based for loops work a lot like Python’s for loops. Can we implement an analogue of Python’s enumerate() in C++? We can!

Read more

Like many of you, when I work on a graphics project I sometimes have a need to compile some shaders. Usually, I’m writing in C++ using Visual Studio, and I’d like to get my shaders built using the same workflow as the rest of my code. Visual Studio these days has built-in support for HLSL via fxc, but what if we want to use the next-gen dxc compiler?

This post is a how-to for adding support for a custom toolchain—such as dxc, or any other command-line-invokable tool—to a Visual Studio project, by scripting MSBuild (the underlying build system Visual Studio uses). We won’t quite make it to parity with a natively integrated language, but we’re going to get as close as we can.

Read more

NVIDIA recently announced their latest GPU architecture, called Turing. Although its headlining feature is hardware-accelerated ray tracing, Turing also includes several other developments that look quite intriguing in their own right.

One of these is the new concept of mesh shaders, details of which dropped a couple weeks ago—and the graphics programming community was agog, with many enthusiastic discussions taking place on Twitter and elsewhere. So what are mesh shaders (and their counterparts, task shaders), why are graphics programmers so excited about them, and what might we be able to do with them?

Read more

Welcome back! In the last couple of articles, we learned about different ways to understand normal vectors in 3D space—either as bivectors (part 1), or as dual vectors (part 2). Both can be valid interpretations, but they carry different units, and react differently to transformations.

In this third and final installment, we’re going leave behind the focus on normal vectors, and explore a couple of other unitful vector quantities. We’ve seen how Grassmann bivectors and trivectors act as oriented areas and volumes, respectively; and we saw how dual vectors act as oriented line densities, with units of inverse length. Now, we’re going to put these two geometric concepts together, and find out what they can accomplish with their combined powers. (Get it? Powers? Like powers of a scale factor? Uh, you know what, never mind.)

Read more

In the first part of this series, we learned about Grassmann algebra, and concluded that normal vectors in 3D can be interpreted as bivectors. To transform bivectors, we need to use a different matrix (in general) than the one that transforms ordinary vectors. Using a canonical basis for bivectors, we found that the matrix required is the cofactor matrix, which is proportional to the inverse transpose. This provides at least a partial explanation of why the inverse transpose is used to transform normal vectors.

However, we also left a few loose ends untied. We found out about the cofactor matrix, but we didn’t really see how that connects to the algebraic derivation that transforming a plane equation $N \cdot x + d = 0$ involves the inverse transpose. I just sort of handwaved the proportionality between the two.

Read more

A mysterious fact about linear transformations is that some of them, namely nonuniform scalings and shears, make a puzzling distinction between “plain” vectors and normal vectors. When we transform “plain” vectors with a matrix, we’re required to transform the normals with—for some reason—the inverse transpose of that matrix. How are we to understand this?

It takes only a bit of algebra to show that using the inverse transpose ensures that transformed normals will remain perpendicular to the tangent planes they define. That’s fine as far as it goes, but it misses a deeper and more interesting story about the geometry behind this—which I’ll explore over the next few articles.

Read more

Here’s a cute bit of math I figured out recently. It probably doesn’t have much practical application, at least not for graphics programmers, but I thought it was fun and wanted to share it.

First of all, everyone knows about rotations: they make things go in circles! More formally, given a plane to rotate in and a center point, rotations of any angle will preserve circles in the same plane and with the same center. By “preserve circles”, I mean that the rotation will send every point on the circle to somewhere on the same circle. The individual points move, but the set of points comprising the circle is invariant under rotation.

Read more

In two previous articles, I’ve explored some unusual methods of texture mapping—beyond the conventional approach of linearly interpolating UV coordinates across triangles. This post is a sort of continuation-in-spirit of that work, but I’m no longer focusing specifically on quadrilaterals.

A problem that often afflicts texture mapping on smooth, curvy models (such as characters) is distortion: in some regions, the texture may appear overly squashed, stretched, or sheared on the 3D model. A related but distinct problem is that of different regions of the model having different texel density, due to varying scale in the UV mapping. I wanted to explore these issues mathematically. Are there ways to create texture mappings that have low distortion by construction?

Ultimately, I didn’t come to an altogether satisfying resolution of this question, but I encountered plenty of interesting math along the way and I want to share some of it. This post will be on the more esoteric, less immediately-applicable side—but I hope you’ll find the topic intriguing nonetheless.

Read more

It’s been quite a while since the first entry in this series! I apologize for the long delay—at the time, I’d intended to write at least one more entry, but I couldn’t get the math to work and lost interest. However, I recently had occasion to revisit this topic, and this time was able to make progress.

In this article, I’ll cover bilinear interpolation on quadrilaterals. Unlike the projective interpolation covered in Part 1, this method will allow us to maintain regular UV spacing along all four of the quad’s edges, regardless of its shape; but we’ll see that to achieve this, we’ll have to accept a different kind of distortion to the texture.

Read more

Ｕｎｉｃｏｄｅ! 🅤🅝🅘🅒🅞🅓🅔‽ 🇺‌🇳‌🇮‌🇨‌🇴‌🇩‌🇪! 😄 The very name strikes fear and awe into the hearts of programmers worldwide. We all know we ought to “support Unicode” in our software (whatever that means—like using wchar_t for all the strings, right?). But Unicode can be abstruse, and diving into the thousand-page Unicode Standard plus its dozens of supplementary annexes, reports, and notes can be more than a little intimidating. I don’t blame programmers for still finding the whole thing mysterious, even 30 years after Unicode’s inception.

A few months ago, I got interested in Unicode and decided to spend some time learning more about it in detail. In this article, I’ll give an introduction to it from a programmer’s point of view.

Read more