Back in 2013, I wrote a somewhat popular article about pseudorandom number generation on the GPU. In the eight years since, a number of new PRNGs and hash functions have been developed; and a few months ago, an excellent paper on the topic appeared in JCGT: Hash Functions for GPU Rendering, by Mark Jarzynski and Marc Olano. I thought it was time to update my former post in light of this paper’s findings.
With some of my spare time lately, I’ve been enjoying learning about some of the new features in
C++20. Concepts and the closely-related
requires clauses are two great
extensions to template syntax that remove the necessity for all the SFINAE junk we used to have to
do, making our code both more readable and more precise, and providing much better error messages
(although MSVC has sadly been lagging in the error messages department,
at the time of this writing).
Another interesting C++20 feature is the addition of the ranges library (also ranges algorithms), which provides a nicer, more composable abstraction for operating on containers and sequences of objects. At the most basic level, a range wraps an iterator begin/end pair, but there’s much more to it than that. This article isn’t going to be a tutorial on ranges, but here’s a talk to watch if you want to see more of what it’s all about.
What I’m going to discuss today is the process of adding “ranges compatibility” to your own container class. Many of the C++ codebases we work in have their own set of container classes beyond the STL ones, for a variety of reasons—better performance, more control over memory layouts, more customized interfaces, and so on. With a little work, it’s possible to make your custom containers also function as ranges and interoperate with the C++20 ranges library. Here’s how to do it.
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!
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.
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?
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.)
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.
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.
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.
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.
Feedly
RSS