# The time-smeared deer is not in God's Eye View: how the effect works, rebuilt and measured
> Satyajit Ghana — Head of Engineering @ Inkers Technology
> canonical: https://ai.satyajit.si/articles/time-smeared-video-gaussians
> date: 2026-11-09
> tags: 3d, gaussian-splatting, depth, explainer
The post that sent me here is [a quote-post by @Yooeec3](https://x.com/yooeec3/status/2119607354450936250) of [a 17-second clip posted by @AiwithYasir](https://x.com/AiwithYasir/status/2119418166485110850). I watched it as one still per second at 480x270. A camera frustum, with the video frame on its image plane, travels along a drawn path through a dark scene; the patch of meadow in front of it lights up as that frame's reconstruction; and behind it a pale deer's past poses stay standing, fused into one long body bent along the path. A caption in the corner reads "space + time". By the last seconds the meadow is gone and only the smear remains. Yasir's caption describes the method in two lines, "2D video turned into per-frame 3D Gaussians" and "Every moment left precisely in place", and then reaches for the cosmic: "Someone reconstructed space and time itself." The quote-post adds a link: "作者还顺手开源了" (the author also open-sourced it), pointing at [github.com/bilawalsidhu/gods-eye-view](https://github.com/bilawalsidhu/gods-eye-view).
So I cloned the repository to find the pipeline. It is not there. This piece is three things: what that repository actually is, how the time-smear effect works stage by stage, and a rebuild of the effect in numpy on a synthetic clip, with the numbers that decide whether your own version looks like the viral one or like a cloud of ghosts.
Numbers are labelled **measured** (I computed them from a file or a run of my own code), **reported** (someone else's figure or words, not re-run) or **reasoned** (my arithmetic on the other two).
## Where the link came from, and what it points at
Yasir's post carries no link and no credit. One reply under it reads "Love how you stole this video without credit". A later reply from Yasir himself supplies the link the quote-post repeats: "Bilawal Sidhu's spatial / 4D work: Open-source tool (God's Eye View / WorldView-style globe): https://github.com/bilawalsidhu/gods-eye-view" (**reported**, read through the fxtwitter mirror on 2026-11-09). That reply calls the repository a globe, and it is one.
I cloned it shallow at commit `e5da073` (2026-11-09). **Measured** from that checkout:
- `LICENSE` is MIT, copyright 2026 Bilawal Sidhu; `package.json` names it `gods-eye-view` 0.3.0.
- 3,114 tracked files, 2,459 of them `.js`, `.mjs` or `.vue`.
- The runtime dependencies include Vue, Pinia, CesiumJS (1.138.0 in the lockfile), `satellite.js`, `hls.js`, `mapillary-js`, an ecCodes WASM build for weather GRIB files and a WebUSB software-defined-radio stack. No PyTorch, no ONNX runtime, no model weights, no Python at all.
- `src/layers/` holds 31 layer directories: aircraft, vessels, satellites, earthquakes, CCTV, weather, wind, cyclones, transit, wildlife sightings and so on.
- A case-insensitive search for `gaussian`, `splat`, `chronophot`, `time-smear` and `deer` over every tracked file finds no rendering code. The only "splats" is a variable named `glowPrimitives` reported as "glow splats" in a wildlife-layer performance test, and the rest of the hits are place names in bundled census and OpenStreetMap data (Deer Park, Deer Lodge).
The README's own pitch is "A spy-satellite simulator in your browser": a photorealistic 3D globe with live aircraft, ships, satellites, earthquakes, traffic and public cameras, voice-controlled through the OpenAI Realtime API (**reported**). It is a real and substantial project, and it is the subject of [Bilawal's own post](https://x.com/bilawalsidhu/status/2093798887815348521) from August about reaching the top of GitHub Trending. It is not a video-to-Gaussians tool.
I could not find the deer clip's original author. The fxtwitter profile timeline returned 404 for both Bilawal's and Yasir's accounts on the day I looked, and two web searches turned up nothing that names the clip. Bilawal works on 3D capture and Gaussian splatting, so the attribution is plausible as a guess about a person; it is wrong as a pointer to code. I have not used any frame of the clip here: its rights are unknown, and the repository's own README GIFs are explicitly excluded from the MIT licence ("No permission is granted for standalone reuse or modification", `docs/media/README.md`). Every picture below is from my own run.
There is one honest thread between the two. The globe keeps every past position of a tracked aircraft and draws them all at once: `src/data/trailRenderer.js` describes "One trail = one ENTITY polyline" and notes the tail fade was removed so "the whole history renders at one readable alpha". That is a time smear of a point. The deer clip is the same idea applied to every pixel of a body.
## The idea, minus the cosmology
A video is a function of time. A 4D reconstruction, such as [4D Gaussian splatting](https://arxiv.org/abs/2310.08528), tries to recover a scene that changes with time: at moment $t$ you render the deer where it was at $t$, and nowhere else. The time smear does the opposite. Reconstruct each frame on its own into a set of Gaussians $G_t$, place each set in one shared world frame, and then render the union
$$
G = \bigcup_{t=1}^{T} G_t
$$
from a camera of your choosing, with no notion of time at all. Every pose the subject held is present at once. Nothing about this needs higher dimensions; it needs a mask, a depth map and a camera pose per frame.
The old name for the result is chronophotography. Étienne-Jules Marey exposed one photographic plate many times while a bird or a runner crossed in front of it, and the plate held every phase of the motion side by side; Yasir's own reply under his post points at Harold Edgerton's strobe photographs and Duchamp's *Nude Descending a Staircase*. Marey had one advantage this pipeline lacks: his camera did not move, so every exposure was already registered to every other. Once the camera moves, someone has to put each frame back in the right place, and that is where all the difficulty sits.
## The pipeline, stage by stage
Nothing in the posts names the models used, so the stages below are the minimum such a pipeline needs (**reasoned**), each with the kind of off-the-shelf model that does the job today.
**1. Segment the subject in every frame.** You want the deer and only the deer. A promptable video segmenter does this: click the animal once, and the mask is propagated through the clip. SAM-family models are the default; I have written about [SAM 3 as ONNX files](/articles/sam3-onnx) and [SAM 3.1's multi-object tracking](/articles/sam-3-1-object-multiplex). The mask's count is the subject's pixel count, and that number becomes the per-frame Gaussian budget.
**2. Lift each frame to 3D.** Two routes. A monocular depth model gives a depth per pixel, and each masked pixel becomes a 3D point, or a small Gaussian whose size is its pixel's footprint at that depth. Or a feed-forward image-to-Gaussians network predicts the Gaussians directly, typically one or a few per pixel. Either way the count scales with masked pixels. The catch is that many depth models predict *relative* depth, correct up to an unknown scale and shift that changes from frame to frame; [Depth Anything 3's metric output needs a wrapper to become metres](/articles/depth-anything-3-ros2). Check the licence of whichever you pick: Depth Anything V2's small checkpoint is Apache-2.0, its larger ones are non-commercial.
**3. Register every frame into one world frame.** You need each frame's camera rotation $R_t$ and position $C_t$. The background is static, so structure-from-motion (COLMAP) on the background pixels, with the subject masked out, recovers them; so do the newer feed-forward pose-and-geometry models covered in [streaming reconstruction from unposed video](/articles/da3-streaming-reconstruction). The same background also fixes stage 2's scale problem: fit each frame's relative depth to the background's known geometry, frame by frame.
**4. Back-project and accumulate.** For a masked pixel $(u, v)$ with depth $z$ and intrinsics $K$:
$$
\mathbf{X} = R_t \, z \, K^{-1} \begin{bmatrix} u \\ v \\ 1 \end{bmatrix} + C_t .
$$
Do it for every masked pixel of every kept frame, and never delete anything. The background is reconstructed once, from a handful of frames, as an ordinary static scene.
**5. Render from a new camera.** The union is just a large static splat scene. A standard rasteriser draws it from any viewpoint; the viral clip watches from a high, distant viewpoint that takes in the whole path, a god's-eye view. ([My capture-pipeline piece](/articles/3dgs-capture-pipelines) covers the rendering side.)
## Rebuilding it on a clip with known answers
I wanted numbers I could check, so I made a clip where every answer is known. A short numpy ray caster renders a 5-second scene at 30 fps and 320x180: a rolling meadow from a sum of sines, seven trees, and a deer built from ten ellipsoids (body, neck, head, ears, tail and four legs swinging at 1.4 strides a second) walking a curved path at about 1.25 m/s. A handheld camera walks sideways 1.6 m above the ground, bobbing slightly and panning to follow. The renderer returns, for every frame, the colour, the true subject mask, the true depth and the true camera pose. Rendering the 150 frames took 208.3 s on this shared CPU (**measured**).
Then the pipeline above, in a couple of hundred lines of numpy: the mask is the deer's pixels, each one is back-projected with its depth and pose, the background is back-projected from every 15th frame (10 frames, depth under 30 m), and everything is drawn from a camera 15 m up with a z-buffered disc per point, sized by its source pixel's footprint. Figure 1 shows one frame through the stages.
The background shows streaks and holes. That is the honest look of a point cloud lifted from 10 low-resolution frames at a grazing angle: the ground far from the camera gets few pixels, and the patch the deer stood in front of was never seen. A real pipeline trains a proper static splat for the background and fills those in. The deer is clean because it is close to the camera and because the depth is exact. Keep every frame and you get Figure 2.
That is the effect, and it falls out of five lines of geometry. The rest of this piece is about what it costs and what breaks it.
## What one frame costs, and what the clip costs
Each masked pixel is one Gaussian. In my clip the deer covers between 788 and 1,092 pixels per frame, median 933, which is 1.6% of a 320x180 frame. All 150 frames together hold 142,217 (**measured**).
How many bytes is a Gaussian? The standard 3DGS `.ply` stores 62 float32 per Gaussian at spherical-harmonic degree 3: position, a normal field nobody uses, three DC colour terms, 45 higher-order colour terms, opacity, three scales and a four-component rotation. That is 248 bytes. A view-independent colour (degree 0) without the normal is 14 floats, 56 bytes (**reasoned** from the format).
| Kept frames | Copies | Gaussians (measured) | SH degree 3 | SH degree 0 |
|---|---:|---:|---:|---:|
| every frame | 150 | 142,217 | 35.3 MB | 7.96 MB |
| every 5th | 30 | 28,532 | 7.08 MB | 1.60 MB |
| every 15th | 10 | 9,575 | 2.37 MB | 0.54 MB |
Those are small because 320x180 is small. The same framing at 1080p has 36 times the pixels, so every frame of the 5-second clip is 5,119,812 Gaussians, 1.27 GB at degree 3 and 0.29 GB at degree 0; every 5th frame is 1,027,152 and 255 MB (**reasoned**: measured counts times 36). A feed-forward model that predicts more than one Gaussian per pixel multiplies that again. This is the practical reason to subsample frames, and it does not hurt the look as long as the copies still overlap.
When do they overlap? The deer moves about 1.25 m/s, so keeping every $k$-th frame at 30 fps spaces the copies $1.25\,k/30$ metres apart. Its body ellipsoid is 1.24 m long. Below that spacing the copies fuse into the continuous "millipede"; above it they separate into a row of statues (**reasoned** from the scene's parameters). At every 5th frame they sit 21 cm apart, six bodies deep, which is why Figure 2 reads as one form. The widget below draws 40 real points per kept frame from that run.
Two things to notice. First, each copy is a shell: only the side facing the camera exists, because only that side had pixels. In my run the centroid of a frame's deer points sits a mean 12.4 cm (max 17.6 cm) off the true body's centre line in plan view (**measured**), all of it toward the camera. Orbit far enough round the smear and you look into hollow deer. Second, the legs carry the motion. The body is a near-rigid tube that only slides, so its copies blur into one surface; the legs swing, so their copies fan out along the path, which is where the "great millipede" in Yasir's caption comes from.
## Where it breaks: registration
Every frame's points are only as well placed as its camera pose. A rotation error of $\theta$ moves a point at range $r$ sideways by about $r\,\theta$. To see how fast that adds up, I perturbed each frame's true rotation by a random rotation with a per-axis standard deviation $\sigma$ and re-ran the accumulation (**measured**, all 150 frames, deer at a median range of 9.21 m from the camera):
| Pose error per axis | Deer copy displacement, RMS | Max | Background point displacement, RMS |
|---|---:|---:|---:|
| 0.1° | 2.2 cm | 4.6 cm | 3.4 cm |
| 0.25° | 5.6 cm | 11.7 cm | 7.8 cm |
| 0.5° | 11.7 cm | 26.4 cm | 14.1 cm |
| 1° | 22.5 cm | 51.0 cm | 28.8 cm |
| 2° | 44.0 cm | 1.10 m | 46.8 cm |
The deer column matches the small-angle prediction: two of the three rotation axes move a point sideways, so the expected RMS is $\sqrt{2}\,r\,\sigma$, which at 9.21 m and 1° is 22.7 cm against the 22.5 cm measured (**reasoned**, then checked). The background column is larger because the background is farther: its median range is 10.6 m and its far points reach 30 m.
What matters for the look is the ratio of that error to the spacing between copies. At 1° the copies wander 22.5 cm while sitting 21 cm apart, so the smooth tube of Figure 2 turns into a jagged one, and the trees and bare-earth patches of the background are drawn several times over, slightly rotated. A converged structure-from-motion solve on a well-textured static scene usually lands at a small fraction of a degree (**reasoned**; it depends heavily on the footage), which is why a careful pipeline gets a clean smear and a careless one does not.
The viral clip, as far as I can tell from its stills, also dodges the background half of the problem: it shows only the current frame's patch of meadow and keeps only the deer from past frames. Nothing static is drawn twice, so nothing static can ghost. The toy below is the same geometry in the plane, with a depth-scale error added.
## Where it breaks: relative depth
Stage 2's depth model is the other place a frame can land wrong, and its errors run along the ray instead of across it. I simulated a relative depth model the way such models behave: each frame's output is an affine function of inverse depth, with a scale and shift that drift between frames (log-scale standard deviation 0.15), times 2% per-pixel noise. Then two ways to turn it into metres:
- **Aligned per frame.** Fit each frame's scale and shift by least squares against the background's known depth at that frame's background pixels, then apply them to the deer. Deer copies end up 0.78 cm RMS (max 1.98 cm) from where true depth puts them (**measured**).
- **Aligned once.** Fit on the first frame only and reuse that scale and shift for the whole clip. Copies end up 2.10 m RMS (max 4.60 m) from where they belong (**measured**): each one slides toward or away from the camera along its own ray, and the smear becomes a scatter.
That factor of about 270 is the whole argument for per-frame alignment. A model that outputs metric depth narrows the gap but does not close it, because its metric scale is itself an estimate per frame; anchoring every frame to the static background is the step that makes the copies agree.
## Where it breaks: the edge of the mask
The last failure is the one you see in almost every monocular point cloud: flying pixels. A depth model blurs depth across an object's silhouette, so a pixel on the deer's edge gets a depth somewhere between the deer and the meadow behind it, and lands in mid-air. A mask that bleeds a pixel past the true edge makes it worse by adding background pixels that also get blurred depth.
I blurred each frame's true depth with a 3x3 box filter and dilated the mask by one pixel. That adds 36.6% more points than the true mask, and 113,373 of the 194,264 points (58.4%) land more than 30 cm from where true depth would put them. Of the deer's own pixels, 44.9% do (**measured**). The share is high because the subject is small: at 320x180 the legs are two or three pixels wide, so nearly every leg pixel is an edge pixel. At higher resolution the proportion falls, since edge pixels grow with the outline and the mask with the area, but a 1-pixel blur at 1080p still throws the thin parts (legs, ears, antlers) into streaks (**reasoned**). The fixes are standard: erode the mask by a pixel or two, and drop any point whose depth disagrees with its neighbours' by more than a threshold.
Figure 3 puts the three failures next to the clean result.
## What I ran, and what I did not
**Ran:** the synthetic clip renderer and the full mask, depth, pose, accumulate and render pipeline, in numpy on CPU. The counts, byte sizes, pose-noise table, depth-alignment comparison and flying-pixel shares above all come from it. I also cloned the God's Eye View repository and searched and read it.
**Did not run:** any real segmentation, depth or image-to-Gaussians model. This sandbox has no PyTorch, and the point of the experiment was geometry with known answers, which a real model would have blurred. So my "depth model" is a simulation of how relative depth errs, not a measurement of any particular network's error, and my Gaussians are discs sized by their pixel footprint, not trained or predicted ellipsoids. I did not reproduce the viral clip, whose source video, models and code I could not find.
**What would change with real models:** mask edges get softer than my exact mask, so the flying-pixel step matters more; depth error is larger and structured (worse on thin parts and on fur), so per-frame alignment matters more; and feed-forward Gaussians carry their own opacities and orientations, so each copy looks less like a shell of dots and more like a solid surface.
## So what is the takeaway
The clip is lovely, and the method behind it is ordinary 3D vision: mask, depth, pose, back-project, never delete. The novelty is the decision to keep every frame and render the union, which turns a reconstruction pipeline into a chronophotograph you can fly around. If you build one, the numbers above say where the effort goes: keep pose error well under the copy spacing divided by the subject's range (at 9 m and 21 cm spacing, under about a degree, and a tenth of that for a clean look), align relative depth per frame to the static background, erode the mask, and subsample frames so the copies still overlap, since every kept frame at 1080p costs tens of thousands of Gaussians.
And the link that travelled with it points at a different project. God's Eye View is an MIT-licensed live-data globe that is worth a look on its own terms. It does not make Gaussians.