Home / Video / Scenes and Storyboards

The Cosmos Film: Why It Feels Off, and a Process to Make It Awe-Inducing

Updated Jun 17, 2026 · Affirmology_CosmosFilm_EvolutionProcess_v1.md

The Cosmos Film: Why It Feels Off, and a Process to Make It Awe-Inducing

Written after reading the full Affirmology_Primer_B2.html engine (Cowork lane, 2026-06-17). For Jeff, and shared with Claude Code. No em dashes, per house rule.

First, the honest diagnosis

Your gut is right, and the good news is that "it's kind of shit but has potential" is exactly correct in a fixable way. What feels wrong is actually two separate problems that get blamed as one. Keeping them separate is the whole key.

Problem one: readability (a deterministic bug, fixable in code today)

The "text on top of text" is not a taste problem, it is a scheduling collision. Every text beat is pinned to the exact same spot (dead center of the screen), and several beats have overlapping time windows, so two captions sit on top of each other. Concrete examples from the current file:

• 4.6s to 7.8s: "the sky made a shape" is drawn on top of "The night you were born," which has not faded yet.
• 22.4s to 25.4s: "So much to learn" lands while "the keys that code you" is still on screen.
• Throughout the systems section, the chart artwork itself contains text (the Gene Keys labels "Life's Work / Evolution / Radiance," the titles "ACTIVATION"), and those sit in the same center zone as the captions, so word piles on word.

This is fixable without any art: enforce that a beat fully clears before the next begins, give the chart-art labels their own zone away from the caption line, and never run a full-screen caption at the same moment as a label-heavy chart. Cowork can audit the timeline and hand Claude Code the exact corrected in/out times.

Problem two: the visuals look lame (NOT a code problem, an asset problem)

This is the important one. For all its power, the engine is being asked to invent beauty from scratch in real time, and it is doing it with the crudest possible primitives:

• The zodiac figures are literally line segments between a handful of hardcoded points with 3px white dots. Connect-the-dots.
• The Gene Keys "sequence" is four hollow circles on a flat horizontal line with text under each. Not a wheel, not alive.
• The meditating body is a circle (head) plus a triangle (torso) plus a line (spine).
• The cosmos is particle dots plus a few blurry radial-gradient blobs plus fog.

No amount of GSAP tuning makes connect-the-dots look cinematic. The browser is a brilliant compositor and animator and a terrible illustrator. We have been using it as the illustrator. That is the root cause.

The principle that fixes everything

Stop asking the browser to be the artist. Make it the compositor and the conductor.

The hand-built engine's real superpowers are precision, synchronization to Lily's voice, chart-specific personalization, interactivity, and resilience (it runs on any phone). Its weakness is generating gorgeous imagery. So we flip the division of labor: beautiful imagery comes in as pre-made assets, and the engine arranges, reveals, lights, and syncs them.

Once you make that flip, your instinct about providing graphics is not just helpful, it is the single highest-leverage move available.

Your real question: yes, you can provide graphics, and it changes everything

Here is exactly what to provide, in rough order of impact:

1. A cinematic cosmos background, as a video loop. The biggest win by far. One real nebula-flythrough clip (from Higgsfield, or stock like Artgrid, or a Blender render) playing as the base layer instead of the particle-and-blob cosmos. This alone moves the film from "screensaver" to "trailer." The engine just plays it underneath and controls its speed for the warp moment.
2. Hero art for each system, as transparent PNG or SVG. A genuinely beautiful natal chart wheel, a real bodygraph, a Gene Keys wheel, elegant gold zodiac line-art, a glowing brain. Drawn by a designer, generated, or sourced, then exported clean on transparent backgrounds. The engine lights them up and draws them on in sequence, instead of inventing dots. Vector (SVG) is ideal because it stays razor sharp and we can animate strokes and glows on it.
3. Texture and light overlays. Film grain, soft light leaks, a gold bokeh pass, a lens-flare for the bloom. These are what separate "rendered by a pro" from "drawn by a program."
4. Reference frames for "awe." Even just 3 to 5 stills or a clip that capture the feeling you want (the 2001 quantum-leap, a specific nebula look). Pin them so "good" stops being subjective.

Format notes so they drop straight in: SVG for anything line-based (charts, glyphs), PNG with transparency for glows and textures, MP4/WebM (or a transparent ProRes/WebM) for moving backgrounds, all sized generously (at least 2x the display size). Drop raw or rough versions in and Cowork will clean, recolor to the brand palette, and export them named to the right slots. You do not have to make them perfect.

Higgsfield versus the hand-built film: they merge, they do not compete

You are right to wonder, and the answer resolves the worry: these are not an either-or, and neither supersedes the other. Each is good at the thing the other is bad at.

• Higgsfield / rendered video is the artist. Use it for the organic, cinematic, hard-to-hand-draw beats: the cosmos flythrough, the warp, the brain absorption, the transcendent light in and out. These are the awe.
• The hand-built GSAP / Three engine is the conductor. Use it for what video physically cannot do: sync every word to Lily's voice to the frame, draw in this person's actual chart, light systems up on cue, stay interactive, and degrade gracefully.
• They stack. The HTML film can play the Higgsfield footage as its background layer and composite the precise, personalized, text-synced overlay on top. So the work you are doing now is not throwaway even if Higgsfield gets great. The film becomes the frame that holds the rendered footage and makes it personal.
• And it is the backup you already named. If a video will not load on someone's phone, the hand-built film still runs. That resilience is worth keeping regardless.

Recommendation: keep investing in the hand-built film, but only as compositor and conductor. Pour the "make it beautiful" energy into provided assets and Higgsfield footage, not into procedural drawing code.

A process the three of us can actually run

The current loop is: Claude Code ships a 3MB blob, you watch the whole thing, react holistically ("it's shit"), repeat. That loop is slow and hard to act on. Here is a tighter one.

1. One shared storyboard is the source of truth. A table with one row per beat: time window, the VO line, what is on screen, what text shows, which asset it needs, and a status. All three of us edit this one doc. Feedback attaches to a beat, not the whole film. A starter version is at the bottom of this doc.

2. Review stills, not the whole film, most of the time. Claude Code can render headless on the Mac, so for each pass it exports a contact sheet of key frames (one still at each beat's peak), the same montage discipline we use for the reports. You mark each frame good or needs-work in seconds, beat by beat. We only watch the full motion film at milestones, once the frames are right. The engine already has a seek hook (window.__seek(t)), so jumping to any beat is trivial.

3. Fix the two problem types on separate tracks. Readability and timing collisions get fixed as code (Cowork audits the timeline, Claude Code applies). Aesthetic quality gets fixed as assets (you and Higgsfield supply, Cowork preps, Claude Code composites). Never let a "looks lame" note get answered with a code tweak, or a "text overlaps" note get answered with new art.

4. Pin what "awe" means. Drop reference frames in the storyboard so the target is concrete.

Roles

• Jeff: taste director and asset provider. React to the still contact sheets per beat, supply or source hero graphics and reference, write the Higgsfield prompts (or approve mine), make the calls.
• Claude Code (Mac): builder, compositor, renderer, deployer. Owns the engine, wires in assets, renders the contact sheet and the film, self-verifies, deploys. The heavy lane.
• Cowork (me): critic, code-auditor, asset prep, spec keeper. I read the timeline and catch the readability and timing bugs (like the collisions above), maintain the storyboard, clean and recolor and export the graphics you drop, write Higgsfield prompts and asset specs, and keep PROJECT_STATE synced. I cannot render the film in my sandbox, so I work from the code and from Claude Code's contact sheets.

The asset pipeline

A shared film-assets/ folder inside the project. You drop raw graphics and reference there. I convert them to brand-correct, transparent, correctly named assets against the storyboard slots. Claude Code pulls them into the film. Clean handoff, no guessing.

Immediate next actions

1. Cowork: audit the full beat timeline and deliver Claude Code an exact list of corrected in/out times so no two captions ever overlap and chart-labels never collide with captions. (Can start now, no assets needed.)
2. Claude Code: when it surfaces from the current build, export a key-frame contact sheet of B2 so we can mark it up beat by beat.
3. Jeff: pick the single cosmos background direction (one Higgsfield clip or one stock nebula) and 3 reference frames for the overall feel. That one decision unlocks the biggest visual jump.
4. All: fill in the storyboard below together.

Starter storyboard (fill in together)