How Rendering Makes an Image

I am going to teach you how a rendered image is actually produced. Forget “drawing objects.” A renderer fills a grid of numbers. Those numbers become pixels after display conversion. Until you understand that, every later topic will feel like magic.

A pixel is not a point in the world. It is an estimate of light arriving through a small region of the image plane. That region may see one surface, several surfaces, motion over time, or a blurry lens sample. Rendering begins as a sampling problem.

Left: rasterization projects geometry onto the image. Right: ray tracing asks what each image sample sees.

The two questions every sample answers

For each sample you compute:

1. Visibility. Which surface is seen through this sample?
2. Shading. How much light leaves that surface toward the camera?

Keep these separate. Wrong visibility cannot be fixed by a clever material. Correct visibility with wrong lighting still looks dead.

A ray tracer answers visibility by casting a ray and taking the nearest valid hit. A rasterizer answers it by projecting primitives, generating fragments, and comparing depth. Both pipelines end with a surface point, a normal, a material, and a lighting calculation.

Rasterization and ray tracing

Rasterization works from objects toward pixels. Transform triangles, clip, project, fill covered samples, keep the nearest depth. Modern GPUs are built for this path. Primary visibility is fast and regular.

Ray tracing works from samples toward objects. A ray starts at the camera, passes through an image sample, and queries the scene for the closest intersection. The same query style supports shadows, reflections, and refractions. Secondary visibility is natural. Naive testing of every primitive is not.

Neither algorithm is a lighting model. You may ray-trace a cartoon shader. You may rasterize a physically based scene. Visibility method and shading model are independent choices. Production systems combine them.

Linear light, then display

Store working color in linear floating point. Half the radiance must remain half the number. sRGB encoding is for files and monitors, not for intermediate lighting math.

A minimal pipeline:

scene description
  -> camera sample
  -> visibility query
  -> surface shading
  -> accumulate in a linear buffer
  -> divide by sample count
  -> exposure and tone mapping
  -> sRGB encoding
  -> image file or display

If you light in sRGB values, dark edges, broken blends, and false material energy appear immediately. That is not a taste issue. It is incorrect arithmetic.

Conventions are part of the course

Before intersections, fix and write down:

• camera looks along +Z or -Z
• Y-up or Z-up
• row vectors or column vectors
• triangle front-face winding
• valid ray interval [t_min, t_max]

Any consistent convention works. Mixed conventions produce mirrored images, inverted normals, and rays that appear to travel backward. Camera rays use a small positive t_min. Shadow rays stop before the light. Reflection rays start slightly off the surface.

First exercise

1. Render one sphere on a constant background.
2. Color it by mapping the unit normal from [-1, 1] to [0, 1].
3. Add a plane and a second object that overlaps the sphere.
4. Move the camera, not the objects.

If nearer surfaces keep winning and the image remains coherent, nearest-hit selection and the camera basis are probably correct. Do not add complex materials until this normal view is trustworthy.

Common errors

• Treating the pixel center as the entire pixel
• Lighting in display-encoded values
• Calling ray tracing a material model
• Accepting hits behind the origin or beyond a light
• Decorating a broken visibility path with advanced BRDFs

Master the image formation chain first. Every later chapter improves one link in that chain.