rendering-design-literature-first

name	rendering-design-literature-first
description	When designing a Titan rendering change, consult the realtime-rendering skill literature to validate architecture before presenting approaches to the user — never ask the user to choose between approaches the literature already answers.
source	auto-skill
extracted_at	2026-06-16T05:16:48.747Z

Rendering Design: Literature-First Validation

When designing a Titan rendering architecture change, the realtime-rendering skill's reference library is authoritative. Before presenting tradeoffs or asking the user to choose between approaches, pull the relevant topic files and validate that each candidate approach aligns with the literature's canonical shape. Present only the literature-supported answer.

Trigger

Invoke when brainstorming a Titan rendering design that involves:

• Geometry visibility / occlusion culling
• Shadow techniques (CSM, VSM, HWRT, SDF)
• GPU-driven rendering / indirect dispatch
• Pass ordering or resource routing
• Denoiser architecture
• Any multi-subsystem rendering change

Procedure

1. Identify the subsystems touched. Name the realtime-rendering topic files that cover each subsystem (geometry-mesh-shading, lighting-shadows, architecture-render-graph, denoising, lighting-gi, etc.).

2. Pull the topic files AND cross-cutting references. Read the relevant topic files plus technique-compatibility.md (for composition/conflict rules) and interactions.md (for ordering/precision/handoff rules).

3. Validate each candidate approach. For each design option, check:

   • Does the literature describe this shape as canonical?
   • Are there documented interactions that conflict with it?
   • Is it listed as mutually exclusive with something already in the stack?
   • Does technique-compatibility.md classify it correctly in the slot?

4. Present the literature-backed answer. State which approach the literature supports, with the specific citation (topic file + section). If the literature genuinely supports multiple options equally, only then present tradeoffs for the user to decide.

5. Record any new cross-cutting findings. If the design reveals an interaction not yet in interactions.md or technique-compatibility.md, flag it for the main chain.

Anti-pattern

Wrong	Right
"Here are approaches A, B, C — which one do you prefer?"	Pull the literature, find the canonical answer, present it.
Presenting tradeoffs based on personal judgment about what "seems right"	Citing the specific topic file and section that settles the question
Asking the user about per-pass occlusion opt-in flags	geometry-mesh-shading.md § GPU-driven rendering: all raster passes use the same indirect buffer

Example from 2026-06-15 occlusion culling design

User asked for occlusion-culled raster. I presented A/B/C approaches (full indirect, deferred-only, per-pass opt-in). User redirected: "consult the real time rendering skill literature." The literature (geometry-mesh-shading.md § GPU-driven rendering, technique-compatibility.md § Geometry/visibility) stated unambiguously: HZB occlusion prunes all batches before rasterization; one indirect buffer feeds all passes. Approach A was the only literature- consistent option.

Same pattern repeated for ray-traced shadow caster set: user said "also remember that ray traced shadows should be able to cast shadows from occluded geometry. consult the literature for how to do this." The literature (lighting-shadows.md § HWRT, geometry-mesh-shading.md § Scene BVH disambiguation table) showed TLAS is built from frustum-visible instances independent of HZB — two separate visibility sets. Presented as confirmed architecture, not as a choice.