A ray is a half-line that starts at a point and extends indefinitely in one direction.

In the context of ray marching etc., a ray could be a view ray, i.e. a ray that starts at the camera, extending through the screen, possibly intersecting with objects in the scene, or a secondary ray, i.e. a ray generated from the intersection of other rays, e.g. shadow rays, reflection rays, or refraction rays.

A ray anchored at origin \(\boldsymbol {r}_o\) in the direction of the unit vector \(\boldsymbol {r}_d\) can be parametrically defined as a ray equation \[ \boldsymbol {r}(t)=\boldsymbol {r}_o+t \boldsymbol {r}_d \]

Plugging the ray equation \(r: \mathbb {R} \rightarrow \mathbb {R}^n\) into the function \(f: \mathbb {R}^n \rightarrow \mathbb {R}\) that defines the implicit surface produces the composite real function \(F: \mathbb {R} \rightarrow \mathbb {R}\) where \(F=f \circ \boldsymbol {r}\) such that the solutions to \[ F(t)=0 \] correspond to ray intersections with the implicit surface. Theses solutions are also called the roots of the function \(F\).

The ray-casting/ray-tracing/ray-marching algorithms simply apply one of the multitude of root finding methods to solve the ray intersection equation.

In general, ray-tracing typically uses a bunch of geometry (e.g. closed-form formulas) to calculate the intersection point, while ray-marching marches along the ray, and uses numerical methods to find the intersection point.

The term ray-casting was introduced concurrently with ray-tracing in the 1980s, nowadays it could be used to mean the general ray intersection process, or specifically the ray-marching process with fixed step size.

To render a scene, the Ray marching algorithm marches a ray from an origin towards a direction. At each step, the algorithm marches a short (possibly changing) distance and checks if a ray intersection occurs. This process continues until a stopping condition is met. The information obtained from the ray intersection is then used to determine the color of a pixel on the screen.

A view ray has the origin at the camera, the direction is determined by the pixel on the screen that it passes through. It may intersect with a surface in the scene, and the information obtained from the intersection is used to determine the color of the corresponding pixel on the screen.

A secondary ray typically originates from a point on a surface and its direction is determined by the type of ray. For instance, a shadow ray is cast towards a light source to determine if the point is in shadow, while a reflection ray and a refraction ray follow directions based on optics. The information obtained from secondary rays helps determine the color of the corresponding pixel that the view ray passes through.

The ray marching (naïve) algorithm is to march a ray by a fixed step size, check if a ray intersection occurs at each step, until the ray reaches a maximum distance or step count.

Formally, the root found by ray marching (naïve) is the limit point of the sequence defined by the recurrence equation \[t_{i+1} = t_i + \Delta t\] where \(t_0 = 0\) and \(\Delta t\) is the fixed step size.

At each step, the ray marches to \(\boldsymbol {r}(t_i)\), which is usually denoted \(\boldsymbol {r}_i\).

The following renders a scene with a unit sphere at the origin, the camera at \((0,0,8)\) and looking at the origin, through a screen of height 1.0, centered at 5.0 from the camera.

The color of pixels are adjusted so that they are brighter the closer they are to the camera, as if there is a light source at the camera. As it takes a fixed step size of 0.1 (not small enough), the sphere is not rendered smoothly, and clearly shows the stepping artifacts.

/* The SDF for a sphere with radius r */
float sdSphere(vec3 p, float r)
{
  return length(p) - r;
}

/* The SDF for a scene with a unit sphere at the origin */
float sdScene(in vec3 pos) {
    return sdSphere(pos, 1.0);
}

#define EPSILON 0.01
#define T_MAX 10.0
#define DELTA_T 0.1
#define SDF_FUNCTION sdScene

/* Ray marching (naïve) */
float rayMarch(in vec3 ro, in vec3 rd) {

    float t = 0.0;

    while(t < T_MAX) {
        vec3 rt = ro + t * rd;
        float ft = SDF_FUNCTION(rt);
        
        if(ft < EPSILON) return t;

        t += DELTA_T;
    }
    
    return T_MAX;
}

/* The main function to render the scene per pixel */
void mainImage(out vec4 pixelColor, in vec2 pixelCoordinate) {
    
    // set up uv coordinates on the screen
    float aspect = iResolution.x/iResolution.y;
    vec2 uv = pixelCoordinate/iResolution.xy;
    uv -= vec2(0.5, 0.5);
    uv *= 2.0 * vec2(aspect, 1.0);

    // set up camera and view ray
    float observerDistance = 8.0;
    vec3 ro = vec3(0.0, 0.0, observerDistance);
    vec3 ta = ro - vec3(uv, 5.0);
    vec3 rd = normalize(ta - ro);

    // ray march
    float t = rayMarch(ro, rd);
    float hit = t != T_MAX ? 1.0 : 0.0;

    // adjust the color to look just bright enough
    float baseRatio = 0.65;
    // the closer, the brighter
    float distRatio = baseRatio + smoothstep(0.0, 1.0 - baseRatio, 1.0 - t / observerDistance);
    vec3 col = distRatio * vec3(1.0);

    // transparent if not hit
    pixelColor = vec4(col, hit);
}

By convention, the GLSL community uses two-to-three letter variable names. Here are some common abbreviations:

• ro = ray origin
• rd = ray direction
• ca = camera
• ta = target (where the camera is pointing)
• uv = texture coordinates

Source: ⧉