Files
settled-reach/docs/sprints/sprint-16/visual.md
T
jpmschweitzerandClaude Opus 4.6 bccdcfcdcb docs(docs): add frontmatter to all sprint briefings
Standardized YAML frontmatter on all 115 sprint briefing files across
sprints 1-26 with title, description, type, status, sprint number, and
team fields.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-14 00:15:45 +01:00

4.2 KiB
Raw Blame History

title, description, type, status, sprint, team
title description type status sprint team
Sprint 16 — Visual Briefing 3D sprite render pipeline setup sprint archived 16 visual

Sprint 16: Converse — Visual Tasks

Goal: Dialogue becomes a two-way exchange — players pick options and the server responds; NPC information-giving deepens through trust and trait-shaped delivery; the sprite pipeline gets its correct art-direction angle; and housekeeping fixes land across all three active teams.

Branch: visual Agents: Araminta (art direction)

Carry-over from Sprint 15

None. Sprint 15 was 100% complete (16/16 done).

New Tickets

# Title Blocked by
#541 3D sprite render pipeline setup

Use db/connectors/ticket show 541 for full details.

Key Decisions

  • decisions/perception.md — D-019 (camera angle amendment: -72.5° from horizontal = ~17.5° from vertical, "the angle"; Camera3D in the offline 3D pipeline produces sprites at this angle), D-043 (visual style: functional warmth, clean 2D with bold silhouettes), D-044 (visual hierarchy: entity > object > structure, resolution chain 1024→256→64), D-049 (z-level rendering stack, 8 layers)
  • decisions/architecture.md — D-066 (dual-scale grid: 64×64px visual tiles on 1m grid; entity sprites: 24×32px footprint within 64×64px visual tile)

Notes

#541 — 3D sprite render pipeline setup

What to deliver: Establish the offline 3D sprite render pipeline used to produce all entity, object, and wall sprites for the game. This pipeline is a Blender (or equivalent) render setup, not a runtime system.

Camera spec (D-019 amendment):

  • Camera3D positioned at -72.5° from horizontal (= 17.5° from vertical, midpoint of 15-20° range)
  • Orthographic projection (not perspective) to match the Godot gameplay camera model
  • This is "the angle" — all sprites for v0.1 are rendered at this angle

Output spec (D-043, D-044):

  • Source resolution: 1024×1024px (highest fidelity, for outline processing)
  • Working resolution: 256×256px (outlines applied at 4-8px, dark blue-grey #333340)
  • Runtime resolution: 64×64px (bilinear interpolation from 256×256)
  • Entity sprites: 24×32px footprint within the 64×64px visual tile (D-044)
  • Sprites are shape templates — no baked shadows, no baked lighting, no baked mood (lighting is applied at runtime by Godot's PointLight2D pipeline)

Lighting rig:

  • Three-point studio rig (key, fill, rim) to produce clean silhouettes without baked directional shadows
  • Do NOT bake lighting direction into sprites — the runtime Godot lighting system (PointLight2D per fixture) provides all scene lighting
  • Keep surface colors flat and readable; the 3D render should produce crisp outlines and readable silhouettes, not mood-lit final frames

Export process:

  • Document the render settings (resolution, camera angle, lighting rig) so any team member can re-render consistent sprites
  • Export at least one entity test sprite (generic NPC silhouette) and one structural test sprite (wall segment) to validate the pipeline before full production
  • Store render source files in the visual branch; export the runtime 64×64 sprites to client/assets/sprites/ (or the established asset path) for the client team

Blocks #540 (client): The client team cannot implement the camera angle adjustment (#540) until this pipeline produces correctly-angled sprites. Deliver at minimum a test entity sprite and one wall sprite so the client team can begin #540 integration work.

Key constraint from D-066: Entity sprites render across a 2×2 sim tile footprint. The 24×32px entity footprint within a 64×64px visual tile must be respected — test sprites should fit this bounding box so the client's z-sorting logic (y-based sort) remains accurate.

Dependency Chain

#541 (3D render pipeline setup) → #540 (client: sprite camera angle)

PR Workflow

When ready to submit, create a PR with tea CLI. All flags are required to avoid TTY prompts (see CLAUDE.md "Gitea access" section):

tea pr create --repo jpmschweitzer/settled-reach --login schweitz --title "feat(assets): 3D sprite render pipeline setup (D-019 angle)" --description "body" --base main --head visual