EN-054: cache the clipmap world-triangle soup on tlas_version#108
Conversation
Every ~10 m of camera travel, the frame that starts an SDF clipmap rebake re-ran scene.build_world_triangles() - re-transforming every vertex of every node and allocating two multi-MB Vecs - even though the soup is a pure function of the scene graph and every mutation path (create/destroy/transform/visibility/geometry) already bumps tlas_version. Travel rebakes now re-BIN against their new origin (which genuinely depends on it) from a cached soup. Cache is a module-local static in gi_bake.rs (the staging.rs store pattern), so the ratcheted renderer/mod.rs gains no field. Measured on the shooter (LOCOPROBE - continuous player travel, probe around the prep): per rebake at 203,446 triangles, gather 2-9 ms -> 0.0 ms on every rebake after the first binning 5-7 ms -> unchanged (origin-dependent, stays) Honest note vs the July audit: the prep measures 7-16 ms per event today, not the 20-60 ms recorded then - the wave-spawn 50-68 ms spikes are only PARTLY this. The gather share is now gone; if the spikes persist, the remainder needs its own probe before further work (EN-054's registry entry should not repeat SH-049's attribution mistake). Verified: 127 shared tests pass; line gate green; 45 s LOCOPROBE run with the cache - identical tri_count through the cached soup, clean stderr, GI serving throughout.
|
Warning Review limit reached
Next review available in: 33 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Implements EN-054. The SDF clipmap's travel-triggered rebake re-gathered the entire scene's triangles every ~10 m of camera movement; the soup is a pure function of the scene graph and
tlas_versionalready covers every mutation path (verified all five bump sites: create/destroy/transform/visibility/geometry). Rebakes now re-bin from a cached soup.Measured (shooter, LOCOPROBE = continuous travel, probe around the prep)
Per rebake at 203,446 triangles:
Honest correction to the ticket: today's prep measures 7–16 ms per event, not the July audit's 20–60 ms — so the 50–68 ms wave-spawn spikes are only partly this. The gather share is gone; if spikes persist, the remainder deserves its own probe first (not repeating SH-049's attribution mistake).
Cache lives as a module-local static in gi_bake.rs (staging.rs store pattern) — ratcheted
renderer/mod.rsgains no field. 127 shared tests pass; line gate green; 45 s travel run clean with identical tri_count through the cache.