Historically, rasterization has been away of putting triangles onto the screen, maybe with a Z-buffer to determine visibility. It's basically an image space ide

Historically, rasterization has been away of putting triangles onto the screen, maybe with a Z-buffer to determine visibility. It's basically an image space idea, with things like Gouraud shading happening in image space, and though you could extend it put it to use in calculating shadow volumes or shadow maps, it doesn't implicitly deal with light transport. That's the first difference. Ray tracing, on the other hand, has always been about (forward or backward) rays of light propagating through object space. It wasn't about light transport in the early days (just visibility and shading, based on simple models like Phong) but it is very well-suited to modelling transport, because it addresses the notion of fully-spatial rays in object space. Writing a physically based (light transport)renderer which was internally based purely on rasterization to rectangular images would be an odd choice, partly because many of the intermediate images would be have to somehow be parameterized to represent locations on a hemisphere, etc. I'm open to correction on this, but rasterization algorithms are really tied to projections onto a rectilinear grid, orthographic or perspective. Ray-tracing doesn't need to assume/know about this raster grid idea and as a result can be used with other geometries. This makes it strictly more powerful than rasterization. This kind of thing, for example: https://www.glassner.com/computer-graphics/graphics-research/cubism-for-computer-graphics/ https://www.glassner.com/computer-graphics/graphics-research... is a very bad fit for polygon rasterizers because each triangle is going to be warped in image space.