| 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
-
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.).
-
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).
-
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?
-
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.
-
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.
