[HIGH] Stabilize sun shadows on LOW preset (camera-angle morphing)

[MichaelFisher1997]

Problem

Shadowing still morphs with camera angle (especially low sun) and shows moving red/green contour bands in debug view.

Scope

Deliver a stability-first shadow baseline for LOW without deep architectural rewrites.

Acceptance Criteria

• Flat world + low sun + camera yaw/pitch sweep does not produce moving contour wedges/bands.
• G debug shadow view remains stable when rotating in place.
• LOW preset honors shadow_cascade_blend as configured.
• No camera-space fade hacks in shader that create view-dependent shadow intensity ramps.
• Keep existing non-shadow rendering behavior unchanged.

Proposed Tasks

1. Normalize LOW shadow policy (explicit mode flags, no implicit behavior from sample count).
2. Remove/replace view-depth low-sun attenuation hacks in terrain shadow path.
3. Validate cascade blend behavior and thresholds for LOW.
4. Add reproducible validation scenario (flat world + tower + low sun camera sweep).

Related Issues

• [HIGH] Simplify RHI composite - Split into focused subsystem interfaces #272 Simplify RHI composite (related, not blocked)
• [HIGH] Decompose World struct - Separate streaming, rendering, and LOD concerns #273 Decompose World struct (related, not blocked)
• [MED] Add debug tooling - Chunk inspector, wireframe modes, performance overlays #275 Add debug tooling (related, helps validation)
• Shadow System Refactoring: SOLID Violations & Monolithic VulkanContext #174 Shadow system refactor (historical context)
• Intermittent massive shadow artifact below player - Shadow system has uninitialized memory and race conditions #243 Prior shadow artifact fix (historical context)

Execution Order

• Do this issue first before deeper shadow refactors.

[opencode-agent]

Based on my analysis of the codebase, here's my assessment of this issue:

Classification: Bug (Stability/Artifacts)

Root Cause Analysis

I've identified the primary source of camera-angle shadow morphing:

1. View-Dependent Cascade Selection (terrain.vert:80-81, terrain.frag:481-485)

The shader calculates vViewDepth using Euclidean distance from camera:

vec3 toCamera = worldPos.xyz - global.cam_pos.xyz;
vViewDepth = length(toCamera);

Problem: As the camera rotates around a fixed world point, the Euclidean distance changes even though the view-space depth remains constant. This causes fragments to hop between cascades based on camera angle, creating the "moving contour wedges/bands" described.

Fix: Use view-space Z depth (along view direction) instead of Euclidean distance to match how CSM splits are actually calculated.

2. LOW Preset Ignores shadow_cascade_blend Configuration

In terrain.frag:233-247, cascade blending is hardcoded (layer < 2) and doesn't respect the shadow_cascade_blend: false setting from presets.json. The shader receives the flag via global.cloud_params.z but never checks it.

3. Implicit Behavior from PCF Sample Count

The shader doesn't have explicit mode flags for shadow quality levels—it infers behavior from shadow_pcf_samples, making it difficult to reason about LOW preset behavior.

Proposed Solutions

1. Fix cascade selection (terrain.vert): Replace Euclidean distance with view-space Z calculation
2. Honor cascade_blend flag (terrain.frag:237): Add check for global.cloud_params.z > 0.5 before blending
3. Add explicit shadow mode flags to distinguish LOW vs HIGH/ULTRA behavior

Information Needed

To proceed with validation:

• Exact reproduction steps: Specific camera angles and sun positions where artifacts are most visible
• Video/screenshots of the red/green debug view showing the moving bands
• Confirmation: Does this affect HIGH/ULTRA presets with shadow_cascade_blend: true, or only LOW?

Would you like me to elaborate on any specific aspect of the shadow stability issue?

opencode session  |  github run