Up until recently, when someone said raytracing, they almost certainly meant rendering the whole scene with ray-based techniques. Meaning...
For each pixel in the image, we fire a ray from the camera through that point in the image plane
We search the scene for where this ray intersects an object, and render a surface there
We calculate the colour of the pixel using the material of the struck surface point, modulated by information from additional rays, such as...
- Rays aimed at light sources to detect intersections with occluding objects, to determine illumination / shadow
- Rays reflected from the hit point to detect intersections with other scene objects and compute their colours to draw specular / mirror-like reflection of other parts of the scene viewed through this surface
- Rays scattered from the hit point to detect intersections with other scene objects and compute their colours to gather diffuse bounced light (global illumination)
Each of these rays can independently searching our whole scene for new intersections, and evaluate material colours the same way, firing subsequent rays of their own... repeating this rendering process down to some maximum recursion depth, so we get extremely accurate calculation of the light bouncing around the scene even between many unrelated surfaces.
This is in contrast to techniques like reflection mapping, shadow mapping, parallax occlusion mapping, etc, which are tricks we can use to add additional detail and effects to scenes rendered with rasterization. In rasterization, we flip the problem: rather than each image pixel searching for the geometry in the scene under it, we take each piece of geometry and compute which pixels it covers:
For each vertex in the scene, we project it into image space
For each triangle, we compute the image pixels/fragments that fall between these transformed vertices in our image plane
For each of these pixels/fragments, we compute the colour by running a shader program that generally has limited information about only the immediate context of this operation.
This is super fast on GPUs, and has historically outperformed raytracing for rendering large complex scenes in realtime. But it has a downside: the information we have at the rasterization/shading stage is usually fairly local to the triangle/fragment we're drawing.
We typically don't have the ability to search the whole scene for arbitrary ray-geometry intersections - so we use approximations. These usually involve looking up some data from a pre-computed texture "map" of the relevant values, which is why you'll often find "mapping" in the names of these techniques.
Instead of casting a ray toward the light and looking for intersecting occluders, we use a shadow map computed in advance or earlier in the frame to decide whether we're in shadow.
Instead of drawing specular reflection by intersecting a reflected ray with the scene and computing the colour of that scene point recursively, we look up a particular pixel from a reflection map (again, either precomputed & baked or updated earlier this frame) to approximate what's probably in roughly that direction.
Although we're computing a reflected ray here, we're not really "tracing" that ray through our scene to find intersections in the same way that a raytracing renderer does. We're just using some similar math to compute a lookup coordinate.
That said, in some cases we can use raymarching with our depth buffer to get more raytracing-like results.
I say "until recently" because new graphics cards are starting to introduce more options for hybridizing raytracing and rasterization techniques. So now on some GPUs and in some circumstances, you can issue ray-geometry intersection searches from pixels of rasterized geometry. It's still costly and needs to be carefully budgeted, but you may find these techniques starting to complement or even displace many of the approximations we've traditionally used in rasterization.