Path Tracing
Overview
This skill provides guidance for tasks involving reverse-engineering ray-traced or path-traced images—analyzing a target image to extract scene parameters (camera position, geometry, materials, lighting) and implementing a renderer that produces a matching output. These tasks typically require achieving high similarity scores (e.g., 0.99+) between generated and target images.
Approach
Phase 1: Analysis Before Implementation
Before writing any rendering code, thoroughly analyze the target image to extract parameters:
- Identify scene components: List all visible elements (sky/background, ground plane, objects, shadows, reflections)
- Sample pixel values systematically: Extract RGB values at key locations to determine:
- Background/sky gradient direction and colors
- Floor pattern (checkerboard scale, colors)
- Object colors and material properties
- Shadow colors and positions
- Derive mathematical relationships: Calculate gradient formulas, pattern frequencies, and geometric positions from sampled data
- Document assumptions explicitly: Write down every derived parameter with justification
Phase 2: Fast Iteration Loop
Establish an efficient testing workflow before attempting full-resolution renders:
- Create downscaled test versions: Use 10-20x smaller resolution (e.g., 240x180 instead of 2400x1800) for parameter tuning
- Calculate expected render times: For path tracing, time ≈ width × height × samples_per_pixel × rays_per_sample. A 2400×1800×100 render means 432 million rays—estimate this upfront
- Implement the exact evaluation metric: If the task uses normalized L2 similarity, implement and track that specific metric, not a proxy like RMS error
- Parameterize the renderer: Create a single codebase where scene parameters can be easily adjusted without rewriting code
Phase 3: Component-by-Component Verification
Verify each scene component independently before combining:
- Sky/background first: Match the gradient exactly in isolation
- Ground plane second: Verify checkerboard pattern scale and colors
- Primary geometry third: Position and size the main object(s)
- Shadows and secondary effects last: These depend on correct primary geometry
For each component:
- Render only that component against a neutral background
- Compare against the corresponding region in the target
- Achieve acceptable error before moving on
Phase 4: Full Resolution Validation
Only after parameters are tuned on low resolution:
- Run a medium-resolution test (e.g., 800x600) to verify scaling
- Execute full-resolution render with validated parameters
- Compare using the exact evaluation metric
Common Pitfalls
Gradient Direction Errors
- Symptom: Sky appears inverted (darker at horizon when it should be brighter, or vice versa)
- Prevention: Sample multiple points along the gradient axis and verify the direction mathematically before implementing
Horizontal vs Vertical Gradient Confusion
- Symptom: Image appears wrong at edges or center
- Prevention: Sample corner pixels explicitly to detect horizontal gradients; document whether brightness increases or decreases toward edges
Arbitrary Parameter Guessing
- Symptom: Making incremental guesses (0.08, 0.09, 0.075, 0.05) without analysis
- Prevention: Use dimensional analysis—calculate expected values from sampled data mathematically
Underestimating Render Time
- Symptom: Timeouts during rendering, incomplete output files
- Prevention: Calculate expected runtime upfront; start with sample counts of 10-30 for testing, only increase for final validation
Proxy Metric Mismatch
- Symptom: Low RMS error but failing the actual similarity threshold
- Prevention: Implement and use the exact evaluation metric from the start
Incomplete Render Validation
- Symptom: Comparing against incomplete/corrupted output files
- Prevention: Verify output file size matches expected dimensions before comparison; check PPM/image headers
Verification Strategies
Pre-Implementation Verification
Parameter Tuning Verification
Final Validation Verification
Process Management
Long-Running Renders
- Use background processes for renders expected to exceed 30 seconds
- Implement progress indicators (line count, file size monitoring)
- Consider incremental output formats that can be resumed
File Format Validation
- Verify PPM/image headers match expected format exactly
- Check for proper line endings and byte counts
- Validate output dimensions match target dimensions
Mathematical Foundations
Ray-Sphere Intersection
For sphere at center C with radius r, ray origin O and direction D:
- Compute discriminant:
b² - 4ac where a = D·D, b = 2D·(O-C), c = (O-C)·(O-C) - r²
- Handle floating-point precision at grazing angles
Checkerboard Pattern
For a floor at y=0 with checker size s:
- Pattern:
(floor(x/s) + floor(z/s)) % 2
- Scale factor must be derived from observed pattern, not guessed
Sky Gradients
- Vertical gradient: Typically based on ray direction's y-component
- Horizontal gradient: Based on ray direction's x-component or distance from center
- Document interpolation formula: linear vs smoothstep vs other
1---2name: path-tracing-23description: Guide for reverse-engineering and recreating programmatically-generated ray-traced images. This skill should be used when tasks involve analyzing a target image to determine rendering parameters, implementing path tracing or ray tracing algorithms, matching scene geometry and lighting, or achieving high similarity scores between generated and target images.4---5
6# Path Tracing
7
8## Overview
9
10This skill provides guidance for tasks involving reverse-engineering ray-traced or path-traced images—analyzing a target image to extract scene parameters (camera position, geometry, materials, lighting) and implementing a renderer that produces a matching output. These tasks typically require achieving high similarity scores (e.g., 0.99+) between generated and target images.
11
12## Approach
13
14### Phase 1: Analysis Before Implementation
15
16Before writing any rendering code, thoroughly analyze the target image to extract parameters:
17
181. **Identify scene components**: List all visible elements (sky/background, ground plane, objects, shadows, reflections)
192. **Sample pixel values systematically**: Extract RGB values at key locations to determine:
20 - Background/sky gradient direction and colors
21 - Floor pattern (checkerboard scale, colors)
22 - Object colors and material properties
23 - Shadow colors and positions
243. **Derive mathematical relationships**: Calculate gradient formulas, pattern frequencies, and geometric positions from sampled data
254. **Document assumptions explicitly**: Write down every derived parameter with justification
26
27### Phase 2: Fast Iteration Loop
28
29Establish an efficient testing workflow before attempting full-resolution renders:
30
311. **Create downscaled test versions**: Use 10-20x smaller resolution (e.g., 240x180 instead of 2400x1800) for parameter tuning
322. **Calculate expected render times**: For path tracing, time ≈ width × height × samples_per_pixel × rays_per_sample. A 2400×1800×100 render means 432 million rays—estimate this upfront
333. **Implement the exact evaluation metric**: If the task uses normalized L2 similarity, implement and track that specific metric, not a proxy like RMS error
344. **Parameterize the renderer**: Create a single codebase where scene parameters can be easily adjusted without rewriting code
35
36### Phase 3: Component-by-Component Verification
37
38Verify each scene component independently before combining:
39
401. **Sky/background first**: Match the gradient exactly in isolation
412. **Ground plane second**: Verify checkerboard pattern scale and colors
423. **Primary geometry third**: Position and size the main object(s)
434. **Shadows and secondary effects last**: These depend on correct primary geometry
44
45For each component:
46- Render only that component against a neutral background
47- Compare against the corresponding region in the target
48- Achieve acceptable error before moving on
49
50### Phase 4: Full Resolution Validation
51
52Only after parameters are tuned on low resolution:
53
541. Run a medium-resolution test (e.g., 800x600) to verify scaling
552. Execute full-resolution render with validated parameters
563. Compare using the exact evaluation metric
57
58## Common Pitfalls
59
60### Gradient Direction Errors
61- **Symptom**: Sky appears inverted (darker at horizon when it should be brighter, or vice versa)
62- **Prevention**: Sample multiple points along the gradient axis and verify the direction mathematically before implementing
63
64### Horizontal vs Vertical Gradient Confusion
65- **Symptom**: Image appears wrong at edges or center
66- **Prevention**: Sample corner pixels explicitly to detect horizontal gradients; document whether brightness increases or decreases toward edges
67
68### Arbitrary Parameter Guessing
69- **Symptom**: Making incremental guesses (0.08, 0.09, 0.075, 0.05) without analysis
70- **Prevention**: Use dimensional analysis—calculate expected values from sampled data mathematically
71
72### Underestimating Render Time
73- **Symptom**: Timeouts during rendering, incomplete output files
74- **Prevention**: Calculate expected runtime upfront; start with sample counts of 10-30 for testing, only increase for final validation
75
76### Proxy Metric Mismatch
77- **Symptom**: Low RMS error but failing the actual similarity threshold
78- **Prevention**: Implement and use the exact evaluation metric from the start
79
80### Incomplete Render Validation
81- **Symptom**: Comparing against incomplete/corrupted output files
82- **Prevention**: Verify output file size matches expected dimensions before comparison; check PPM/image headers
83
84## Verification Strategies
85
86### Pre-Implementation Verification
87- [ ] All scene components identified and listed
88- [ ] Pixel values sampled at 10+ key locations
89- [ ] Mathematical formulas derived for gradients/patterns
90- [ ] Expected render time calculated
91- [ ] Evaluation metric implemented
92
93### Parameter Tuning Verification
94- [ ] Using 10-20x downscaled resolution for testing
95- [ ] Each component verified independently
96- [ ] No arbitrary parameter guessing—all values derived from analysis
97- [ ] Error tracked using exact evaluation metric
98
99### Final Validation Verification
100- [ ] Medium-resolution test passed before full resolution
101- [ ] Output file size/format validated before comparison
102- [ ] Full-resolution render completed without timeout
103- [ ] Final similarity score meets requirements
104
105## Process Management
106
107### Long-Running Renders
108- Use background processes for renders expected to exceed 30 seconds
109- Implement progress indicators (line count, file size monitoring)
110- Consider incremental output formats that can be resumed
111
112### File Format Validation
113- Verify PPM/image headers match expected format exactly
114- Check for proper line endings and byte counts
115- Validate output dimensions match target dimensions
116
117## Mathematical Foundations
118
119### Ray-Sphere Intersection
120For sphere at center `C` with radius `r`, ray origin `O` and direction `D`:
121- Compute discriminant: `b² - 4ac` where `a = D·D`, `b = 2D·(O-C)`, `c = (O-C)·(O-C) - r²`
122- Handle floating-point precision at grazing angles
123
124### Checkerboard Pattern
125For a floor at y=0 with checker size `s`:
126- Pattern: `(floor(x/s) + floor(z/s)) % 2`
127- Scale factor must be derived from observed pattern, not guessed
128
129### Sky Gradients
130- Vertical gradient: Typically based on ray direction's y-component
131- Horizontal gradient: Based on ray direction's x-component or distance from center
132- Document interpolation formula: linear vs smoothstep vs other