Comment by jholman | Hacker News Reader

Comment by jholman | Hacker News Reader

Parent Full thread

Because I am a big jerk, I am going to take this opportunity to complain about a pet peeve, and ask for brainstorming help.

This (generally-pretty-great) book, like many educational materials about computer graphics, makes a terminological choice that I believe to be plainly a mistake. It uses the word "rasterizer" to mean "renderer that works by applying transforms to polygons", as contrastive with a "raytracer" (more generally, a physically-based light transport model). (e.g. "Raytracing and Rasterization, which focus on the two main ways to make pretty pictures out of data").

Properly (from a descriptivist standpoint), a "rasterizer" is any algorithm that transforms vector data into raster data, where rasters are arrays of horizontal lines, each horizontal line composed of pixels. RAYTRACERS ARE RASTERIZERS. (I mean, not if you're using the raytracer to detect collisions or for some other purpose; only if you're using it to generate 2d images of any kind.)

Surely there must be some better terminology for the non-physically-based option? I tend to say "polygon-pusher", but this is my own neologism. Does anyone have any suggestions for a more accurate name for this type of renderer?

Saying "rasterizer" in the sense the book does is as common as saying "literally" to mean "figuratively", as common as writing "there" to mean "they're". So I know that probably there's no fixing it. But I'm still hoping.

The names reflect pretty well what’s in the inner loop. A rasterizer’s outer loop is over the scene (objects/triangles/etc), and the inner loop is over pixels. It does what it says in the sense that it’s rasterizing each primitive one at a time.

A ray tracer, on the other hand, is (sometimes) looping over pixels in the outer loop, and then iterating over objects (“traversing the scene”) in the inner loop.

The existing names are also good descriptors in the sense that they describe the core of what must be computed. A rasterizer always rasterizes. A ray tracer always traces rays but does not always result in pixels, the result can end up in a spatial data structure, it can trace resolution independent shadows & reflections, it can save results in a cache that gets rasterized later, it can end up in multiple pixels (splatting, pixel filtering), etc., etc.. Yes it’s very common to render pixels with a ray tracer, but it’s not required or inherently part of the algorithm, while rasterization doesn’t exist without pixels.

Thanks for pointing this out, I hadn't really thought about it this way.

You're technically correct (the best kind of correct!). Since raytracers draw pixels on the screen, and the screen is an array of horizontal lines, anything that draws pixels to the screen is a rasterizer.

On the other hand, "polygon-pushers" are rasterizers in a deeper sense: triangles are explicitly sliced into arrays of horizontal line segments, and this shapes how everything else works in them, e.g. the need to interpolate attribute values along the edges of each triangle so you can then interpolate them along each raster, etc. Raytracers do no such thing. So all renderers are rasterizers, but some are more rasterizer than others ;)

I also wonder what happens, for the sake of brainstorming, if you change the output to be something that is not a rectangular array of horizontal sets of pixels. In that case you probably wouldn't call a raytracer "a rasterizer" since there would be no raster data, but a polygon pusher would still fit the name, since it uses rasters internally?

BTW, I'll never accept "literally" used as "figuratively", "there" for "they're", or "could care less" unless you do care a little bit. So I don't think you're a jerk, and your comment prompted some interesting thinking!

Note that the interpolating of attribute values along the edges of the triangle is not exclusive to a polygon-pusher, right? If your raytracer has textures, it still interpolates the much same way the polygon-pusher does, right? Am I getting confused? (Of course the raytracer's geometry is less likely to be triangles than the polygon-pusher's geometry, but let's keep it apples-to-apples). And of course it applies to any kind of textures: baked in lightmaps, normal maps, whatever.

I mean, sure, the polygon-pusher presumably does it post-transforms, i.e. in screenspace, and the raytracer does it in some other space (exactly what space is gonna depend on implementation of the camera and stuff I think), but I think it's pretty similar?

But as far as I know the depth-checking in a polygon pusher is totally about the raster, so in that sense, yeah, the (non-wireframe) polygon-pusher has a deeper relationship to rasters.

If you want more technically accurate terms, you might call raytracers and polygon-pushers "image space" and "geometric space" renderers, respectively.

Worth noting that neither method is particularly physically based, and really just boils down to whether you approach the rasterization task "forwards" or "backwards". Which method ends up faster is essentially a function of how much geometry and how many pixels you have.

Follow-up: If you think that "rasterizer" is a good and accurate name for a polygon-transforming renderer, what would you call the rendering technology in the original Battlezone? It's not a ray-tracer. It works by taking line segments expressed as vectors in 3d space, and multiplying them through transformation matrices. But there are no rasters; it outputs to a vector display.

I admit, that's a rare example (though not unique; there's a reason wire-frames, as a display mode, came into existence). But I think it's absurd to say that the rasterizer is the heart of the polygon-transforming approach; the heart is the transformation matrix.

Drawing rasters or on a vector display comes later in the pipeline. Maybe there's a more complex taxonomy?

At the top level, you split polygon-transforming vs ray-tracing (or geometry-main-loop vs pixel-main-loop, or projecting vs searching-from-the-camera, or whatever). Then you split polygon-transforming by output style, raster display vs vector display?

I absolutely agree, drawing rasters or using a vector display (or doing neither, for example doing picking in UX or hitscan in a game) is later in the pipeline. I agree about the more complex taxonomy.

But I don't think it's a branching taxonomy? Both can raster-display, both can vector-display, and both can be used for things other than display. I feel like it's just a 2x3 matrix, or maybe I'm missing some rows columns.

I also agree with your other comment that, even though it's not strictly necessary to do any rasters at all (Battlezone), in 99.99% of cases polygon-pushers are more rasterizer-y than ray-tracers. Even if you're not texturing, you're doing depth occlusion checking (again, Battlezone and other wireframe renderers don't, but yeah, niche), and although there may be some way to do depth occlusion without rasters (z-buffer), I dunno what it is and I've never heard of anyone doing it any other way.

I dunno, when I've taught the material that your book covers (on rare occasion, in less-formal settings), I have definitely felt this need for a raytracer-vs-polygon-projecting taxonomy, and definitely felt a need to talk about rasterizing, but not felt a need to talk about rasterizing in the context of the taxonomy.

Oh come on, don't be pedantic. There is a term for non-physically-based rendered, it's called "rasterization". Just because it's technically incorrect doesn't mean it's any less of a colloquial term. To ignore this is to ignore how language actually works. Even the wikipedia page for Rasterization compares it with ray tracing.

Reply on news.ycombinator.com