3 ms·

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

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.

ggambetta 6y ago
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?
- jholman 6y ago
  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.

ggambetta 6y ago

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?

jholman 6y ago
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.