Research presentation, persistence and engineering tradeoffs

docs/research/README.md

@@ -7,6 +7,7 @@ This is Frontier Systems' version-controlled knowledgebase for design decisions
 | Entry | Topic | Outcome | Evidence limit | Next step |
 | --- | --- | --- | --- | --- |
 | [R-001: modern rendering optimization leads](entries/R-001-modern-rendering.md) | Rendering/performance | proposed | Official engine/vendor guidance and pinned source inspection; no reproduced rendering gains | [E-001: baseline and shared wall resources](experiments/E-001-rendering-baseline.md) |
+| [R-002: fixed ticks, recovery, transport and life support](entries/R-002-fixed-ticks-recovery-and-life-support.md) | Simulation, persistence, multiplayer and engineering design | proposed | Public primary-source review and pinned source inspection; 2026-11-06 follow-up; no experiments run | Select one bounded scenario after confirming current work |
 | [Reference manifest](reference-manifest.csv) | Cross-topic provenance | existing registry | Each row states its reviewed scope and rights limits | Append targeted sources; preserve the CSV contract |
 | [Foundational capability matrix v1](foundational-capability-matrix.v1.csv) | Engineering-game design | existing audit | Historical capability/gap statements have their own evidence dates | Revalidate a row before treating it as current implementation |
 

docs/research/entries/R-001-modern-rendering.md

@@ -52,3 +52,19 @@ Repeated resource construction offers a narrow presentation experiment while pre
 A future comparison should establish actual 1080p render targets and CPU/GPU/frame-tail timing, then change only resource sharing. Supported AA comparisons and room/shadow budgets follow separately. Dynamic geometry makes baked lighting/occlusion less straightforward; visibility must follow authoritative observations without becoming simulation authority.
 
 **No custom GI, deferred renderer, motion-blur or AA rewrite is justified by this entry.** First identify a measured project bottleneck and preserve motion readability. Runtime reproduction, target lower-end hardware, VR/stereo behavior, video publication date and the unreviewed outro remain open. See E-001 for falsifiable controls and acceptance limits.
+
+## Follow-up source review: 2026-10-30
+
+[GPU optimization](https://docs.godotengine.org/en/4.7/tutorials/performance/gpu_optimization.html), Godot documentation contributors, 4.7 documentation (publication date not stated; mutable page, accessed 2026-10-30), describes separate CPU/driver/GPU bottlenecks and notes that overlapping transparent surfaces and shadow/post-processing work can increase fragment cost. This is engine guidance, not a Frontier measurement; the page's API discussion includes older graphics APIs and is not evidence about a particular D3D12 driver.
+
+**Proposed diagnostic:** E-001 adds a separate render-resolution sensitivity comparison after establishing actual viewport sizes and frame pacing. A measurable GPU-time change with resolution is a clue about pixel-dependent work, not proof of a particular shader or whole-game gain. Validate any subsequent optimization with its own fixed-resolution comparison and motion/readability checks. Outcome remains **proposed**, with no run or adoption.
+
+## Follow-up source review: 2026-11-06
+
+**Source:** Godot documentation contributors, [Reducing stutter from shader (pipeline) compilations](https://docs.godotengine.org/en/4.7/tutorials/performance/pipeline_compilations.html), Godot 4.7, publication date not stated; accessed 2026-11-06. The versioned page is mutable and no documentation commit was captured.
+
+**Claim:** For Forward+ and Mobile, the docs describe pipeline precompilation and cumulative compilation monitors. First instancing or newly encountered rendering features can still lead to compilation during play. Shader baking produces an intermediate format, not the final driver-specific pipeline, and headless export cannot perform that baking.
+
+**Frontier evidence:** The pinned [project settings](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/project.godot) declare Forward+ and Windows D3D12. The [existing client benchmark](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/tools/godot/benchmark_client.gd) records frame intervals and render timing for a stationary scene; it does not establish pipeline compilation as a cause of stutter. No compilation monitor or GPU experiment was run here.
+
+**Proposed diagnostic:** In a separately authorized isolated environment, compare a repeatable first encounter with the same subsequent encounter, keeping scene, camera path, renderer, viewport sizes and frame pacing fixed. Record frame-interval p95/p99 and first-encounter spikes alongside compilation-monitor deltas and loading time. Record engine, GPU, driver and actual cache state; if the driver cache is uncontrolled, label the first encounter accordingly. Never delete shared driver caches. Compare visible output and startup cost before proposing any warmup change. **Limit/cost:** compilation counters are cumulative, attribution is correlational, and a warm cache is hardware/driver dependent. No optimization is adopted or performance gain demonstrated. Outcome: **proposed**.