Make Camera Zooms Feel Constant by Interpolating the Log of Scale

A camera zoom that interpolates scale linearly from 1x to 16x lunges forward at the start, then appears to crawl toward the end, even though the scale changes by the same amount on every frame.

The cause is that zooming multiplies positions. With the zoom centered on the origin, a point at position x appears at s * x. Moving from scale s1 to s2 therefore multiplies its on-screen distance from the center by s2 / s1. That per-frame ratio is the number to control.

The technique

Don't interpolate the scale directly. Interpolate its logarithm, then convert the result back:

scale = exp(lerp(log(start), log(end), t))

The program below samples both approaches at 9 evenly spaced values of t, which gives 8 frame-to-frame steps. It then prints each scale and its ratio to the previous frame.

import math

START, END, FRAMES = 1.0, 16.0, 8


def lerp(a, b, t):
    return a + (b - a) * t


def linear_zoom(t):
    return lerp(START, END, t)


def log_zoom(t):
    return math.exp(lerp(math.log(START), math.log(END), t))


def sample(zoom):
    return [zoom(i / FRAMES) for i in range(FRAMES + 1)]


def frame_ratios(scales):
    return [after / before for before, after in zip(scales, scales[1:])]


def spread(ratios):
    return max(ratios) / min(ratios)


linear = sample(linear_zoom)
logarithmic = sample(log_zoom)
linear_ratios = frame_ratios(linear)
log_ratios = frame_ratios(logarithmic)

print(f"Zoom from {START:g}x to {END:g}x over {FRAMES} frames")
print()
print(f"{'frame':>5} | {'linear':>8} {'ratio':>7} | {'log':>8} {'ratio':>7}")
print("-" * 44)
for i in range(FRAMES + 1):
    lin_ratio = f"{linear_ratios[i - 1]:7.3f}" if i else f"{'-':>7}"
    log_ratio = f"{log_ratios[i - 1]:7.3f}" if i else f"{'-':>7}"
    print(f"{i:>5} | {linear[i]:8.3f} {lin_ratio} | {logarithmic[i]:8.3f} {log_ratio}")

print()
print("Largest per-frame ratio divided by smallest (1.000 = constant speed):")
print(f"  linear: {spread(linear_ratios):.3f}")
print(f"  log:    {spread(log_ratios):.3f}")

assert math.isclose(logarithmic[0], START) and math.isclose(logarithmic[-1], END)
assert math.isclose(linear[0], START) and math.isclose(linear[-1], END)
assert math.isclose(spread(log_ratios), 1.0, rel_tol=1e-9)
assert spread(linear_ratios) > 2.0
assert all(a > b for a, b in zip(linear_ratios, linear_ratios[1:]))
Zoom from 1x to 16x over 8 frames

frame |   linear   ratio |      log   ratio
--------------------------------------------
    0 |    1.000       - |    1.000       -
    1 |    2.875   2.875 |    1.414   1.414
    2 |    4.750   1.652 |    2.000   1.414
    3 |    6.625   1.395 |    2.828   1.414
    4 |    8.500   1.283 |    4.000   1.414
    5 |   10.375   1.221 |    5.657   1.414
    6 |   12.250   1.181 |    8.000   1.414
    7 |   14.125   1.153 |   11.314   1.414
    8 |   16.000   1.133 |   16.000   1.414

Largest per-frame ratio divided by smallest (1.000 = constant speed):
  linear: 2.538
  log:    1.000

Reading the table

The linear column adds 1.875 on every frame, but its ratio falls from 2.875 on the first step to 1.133 on the last. The largest ratio is 2.538 times the smallest. That figure belongs to this 1x to 16x, 8-frame example, and a different range or frame count can give a different spread.

The log column has a printed ratio of 1.414 on every step. It doubles every 2 frames, reaching 2x, 4x, 8x and 16x at frames 2, 4, 6 and 8.

The midpoints differ too. At frame 4, the linear zoom is already at 8.500, while the log zoom is at 4.000. Log interpolation reaches the geometric mean of the endpoints halfway through, not the arithmetic mean.

Why it works for any positive range

The constant ratio is not specific to this example. Log interpolation simplifies to:

scale(t) = start * (end / start) ** t

If t advances by a fixed step of 1 / frames, each frame multiplies the scale by the same value:

(end / start) ** (1 / frames)

Here that is 16 ** (1 / 8), or about 1.414.

Constant ratio does not mean constant change in scale. The log version's scale increases by about 0.414 on the first step and about 4.686 on the last.

What the program checks

The assertions cover only this one configuration:

  • Both zooms start and end at the requested scales, within the default tolerance of math.isclose.
  • The log ratios have a spread within a relative tolerance of 1e-9 of 1.0. The printed 1.000 is rounded, so this assertion is the stricter check.
  • The linear spread is greater than 2.0.
  • The linear ratios strictly decrease from frame to frame.

The general claim for other ranges comes from the algebra above, not from these runs.

Where it bites

  • Scale must be positive. math.log raises a ValueError for zero or a negative number, so neither endpoint can be 0x or below with this formula.
  • The endpoint may not be exact. The conversion through log and exp can introduce rounding error, which is why the program uses math.isclose. If you need an exact final value, assign END directly when t reaches 1.
  • **Compute from t, not from the previous frame.** Repeatedly multiplying by a fixed ratio accumulates rounding error and ties the zoom to a fixed frame count. Deriving t from elapsed time and calculating each scale from t avoids both the accumulation and the fixed frame count.
  • Zooming out has the opposite problem. Reversing the linear zoom makes it speed up, with the final frame shrinking the image by a factor of 2.875. The program doesn't run this direction, but it follows from reading the table backward.

Where this stops being enough

This technique covers a single scale moving between two values at a constant ratio:

  • Easing: Applying a non-linear easing curve to t makes the ratio vary, so the zoom is no longer constant. The easing then shapes proportional change.
  • Interrupted zooms: If the target changes mid-zoom, restart from the current scale with a new t. Without extra handling, the speed can jump at that moment.
  • Panning while zooming: This code interpolates only scale. If you also interpolate the camera position separately, the point you're zooming toward can drift. To pin a point, derive the camera offset from the current scale. Moving between distant views may need a path that plans pan and zoom together.

Disclosure: I'm the founder of Homingo; Homingo sells this skill, and this article was written with AI assistance, with the code run before publishing. This is one small idea behind what we package in Isometric Explainers, our Claude Code skill: Claude Code draws how-it-works machines for your docs, blogs and landing pages, with live readouts and built-in layout, motion and geometry checks, and one command turns the same figure into a 1080x1920 explainer reel. Skill Rs 1,499 (about US$17), Complete Kit Rs 2,499 (about US$28; adds 3 more machine reel projects, the finished demo reel, 4 video lessons and a written tutorial), one-time, prices in INR, international cards accepted; it needs Claude access with Claude Code and Node.js 20.10+, Claude plans not included: Isometric Explainers. Everything above works without it.

Comments

Post a Comment

Popular posts from this blog

Catch Overlapping Labels Before Rendering With a Sweep Over X

A label that fits today can land on its neighbor tomorrow when someone renames a metric or adds a series, and you may not notice until the chart is on screen. You can flag likely collisions without rendering by estimating a box for each label and checking the boxes against each other. The technique Each label's box comes from arithmetic on its text: Width is len(text) * size * 0.6 , which assumes an average character is 0.6 em wide. Height is size * 1.2 , which assumes a line height of 1.2 em. Both constants are assumptions, and the program never compares them with rendered text. To find collisions, sort the labels by left edge and walk through them, keeping an active list of boxes that may still overlap something. Each new label does three things: It removes every box from active that ends at or before its own left edge. It tests its y range against each remaining box. It joins active . from dataclasses import dataclass from itertools import combinations CHAR_WIDTH_EM = ...
Read more

Emit an isometric cube as three SVG polygons and test its shared edges

An isometric cube is three polygons that have to meet along identical edges, and a vertex that is off by even one user unit can leave a gap or an overlap. This script emits the three faces with integer coordinates and checks the edges before you trust the SVG. Name the points once All geometry hangs off a center (100, 100) and two offsets, set in cx, cy, dx, dy = 100, 100, round(50 * sqrt(3)), 50 . The program names seven points: C , T , B , UR , LR , LL , UL . Each face is a list of those names. For a 30 degree edge with a vertical rise of 50, the exact horizontal run is 50 * sqrt(3) , which is 86.603. The code rounds it to 87 so every coordinate is an integer and the printed points are exact. The price is that the cube is only approximately isometric: the slanted edges are very slightly off true 30 degrees. from collections import Counter from math import sqrt cx, cy, dx, dy = 100, 100, round(50 * sqrt(3)), 50 print(f"dx = round(50*sqrt(3)) = {dx}; exact value {50 * sqrt(3...
Read more

Shading an isometric box in plain JavaScript: three face tones from one light direction

Flat isometric boxes look like paper cut-outs. Hand-picking three tones for the top, left and right face of every part works for one box, and falls apart at twenty boxes in five colours: you end up with faces that don't agree about where the light is. The fix is small. Choose one light direction, measure how directly each of the three visible faces points at it, and derive every tone from that. This tutorial does it in about 30 lines of JavaScript with no libraries. 1. The three faces and their normals The projection in the listing puts +x running down-right on screen, +y down-left and +z up, so the viewer sits on the high side of all three axes and exactly three faces of a box are ever visible. Each face is described by its normal, the direction it points: const NORMALS = { top: [0, 0, 1], left: [0, 1, 0], right: [1, 0, 0] }; The left face looks toward +y, the right face toward +x. 2. One light, and Lambert's rule Pick the light as a vector pointing from the scene towar...
Read more