Goal: the Nova Drift look

Goal: make Dark Cosmos read like Nova Drift (set 2026-09-23)

Chris, 2026-09-23: “set a goal to work out how to make graphics that look like nova drift, we learned the method but haven’t really managed to achieve it.”

Scope correction (Chris, same day)

“the nova drift graphics i want to replicate is how they made the units look specifically.” The target is unit (ship/enemy) construction: pastel plated bodies, dark seams, facet shading, a tight saturated edge glow, ornate silhouettes. The scene-level work below (lit ground, palette) is secondary and stays behind VisualLook.nova, off by default. Unit findings: the “Unit construction” section of docs/research/2026-09-23-nova-drift-look-gap.md; mockup tool tools/nova_units/nova_unit_bake.py.

Why the last attempt stalled

We researched the glow method (docs/research/2026-07-05-nova-drift-visual-style-tech.md: no shaders, glow baked into stacked sprite layers) and built it (ArchetypeRenderer.USE_BAKED_GLOW, 2026-07-22). Chris judged it weaker than the live shell glow on the TV, and it stayed off.

The same research says glow technique is the smaller half. Its confirmed findings:

• “Neon look = artistic/palette decision, not a rendering technique.”
• The style’s final stage is neon on a detailed background, reached through complex forms + negative-space line art, not filled shapes.

Dark Cosmos today is filled solid shapes on a near-black void, with runtime HDR bloom doing the glowing. So the gap to close is the whole look (palette, value contrast, backdrop, shape language, visual density), not glow alone. Iterating only on glow would repeat July.

Finish line

A switchable NOVA_LOOK render mode that Chris judges, side by side on the Apple TV, as reading like Nova Drift, and that renders no slower than the current look on the ATV (the method needs no bloom, so the realistic hope is faster).

Done means ALL of:

1. Reference board. 8-12 real Nova Drift frames (internal reference only, never shipped or published), each paired with a Dark Cosmos capture of the closest equivalent scene from marketing/capture/shoot.gd, at the same size.
2. Measured gap list. For every trait, a number for both games, not an adjective: background luminance and detail, palette (dominant hues, saturation, how many), value contrast between entities and ground, outline vs fill, stroke width relative to entity size, glow layer count/width/opacity, bullet and enemy size relative to screen, particle density. Ranked by how much each would move the look.
3. Prototype, one trait at a time, behind NOVA_LOOK. Render-only (no /sim, no determinism impact), toggleable at runtime (Debug Settings row) so Chris can A/B it live on the TV. Each trait lands with a before/after capture from the real harness under the real HDR environment (see skill bh-vfx-iteration).
4. Chris’s eye is the test. Each round ends with Chris looking at a real render. Claude never declares a trait “matches” on its own judgment: the July rework needed three rounds of Chris correcting renders that looked right in code.
5. Perf check on the ATV with the PERF_BENCH harness: NOVA_LOOK on vs off, same enemy buckets.
6. Decision: ship as the 0.1 third graphics exception, ship in 0.2, or drop. Chris’s call.

Guardrails

• Must not delay v0.1. This runs alongside it, and ships in 0.1 only if Chris picks it before the other release gates close.
• Competing techniques stay switchable (memory bullet-heaven-toggle-competing-techniques); nothing overwrites the current look until Chris picks.
• Nova Drift art is reference material, never copied into the game or the marketing assets.
• Findings and measurements go in docs/research/, not only in chat.

First step

Build the reference board and the measured gap list (items 1-2). That’s read-only and cheap, and it decides which traits are worth prototyping at all.