fix(geometry): recover RTC offset when the IfcSite placement is forward-referenced#1338
Conversation
…rd-referenced On the streaming-parallel prepass the RTC (relative-to-center) offset is detected from the first ~50 geometry elements' placement chains against a partial, file-head entity index. When a georeferenced model emits the IfcSite *entity* early but its IfcAxis2Placement3D *location* — the point carrying the national-grid offset — as a high (late) express id, the element -> ... -> site chain can't resolve from the partial index and detection returns None. The full-index re-detect that recovers it was gated on `site_position.is_none()` alone, so it was skipped whenever the site entity had already been scanned. The path then fell to `scan_placement_bounds().rtc_offset()`, whose AABB centroid averages the near-origin relative placements against the lone far anchor and lands at ~half the true offset — large enough to pass the >10km shift gate but not enough to bring vertices into f32 range, so geometry shatters into sub-metre quantization noise. Re-detect against the full index whenever no placement samples resolved at all (`!detection_succeeded`), independent of site scan order. Verified end-to-end: affected georeferenced models now report the full-magnitude RTC instead of half. Adds a self-contained regression test (early IfcSite entity + forward-referenced site placement) that pins the partial-index miss / full-index recovery.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
|
Warning Review limit reached
More reviews will be available in 41 minutes and 5 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?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 credits. 🚦 How do rate 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 see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ 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
Problem
Georeferenced models on national-grid coordinates (geometry baked at multi-megametre absolute positions) can render as f32-quantized noise — surfaces shatter into speckle and the model "jitters" on orbit/zoom. It is not a recent regression; it's a long-standing, data-dependent precision bug that only surfaces on the streaming-parallel load path (larger files). The same model loaded under the size threshold (serial path, full index) renders fine, which is why some discipline models in a set looked correct while others did not, and why federating a "good" model rescued a "bad" one.
Root cause
The streaming prepass detects the RTC (relative-to-center) offset from the first ~50 geometry elements' placement chains, resolved against a partial, file-head entity index. When a model emits the
IfcSiteentity early but itsIfcAxis2Placement3Dlocation (the point carrying the world offset) as a high, late express id, theelement → … → sitechain can't resolve from the partial index, sodetect_rtc_offset_from_jobsreturnsNone.The full-index re-detect that would recover the offset was gated on
site_position.is_none()alone — so it was skipped whenever the site entity had already been scanned, even though the site placement hadn't. Detection then fell through toscan_placement_bounds().rtc_offset(), whose AABB centroid(min+max)/2averages the many near-origin relative placements against the lone far anchor and lands at roughly half the true offset. Half is still > the 10 km shift threshold, soneedsShiftistrueand a shift is applied — but it leaves vertices at ~half the world magnitude, still far outside f32's safe range → collapse.Fix
Re-detect against the full index whenever no usable placement samples resolved at all (
!detection_succeeded), independent of site scan order:The full index resolves the forward-referenced
…→sitechain, so the placement-resolved median yields the true full-magnitude offset and the broken centroid fallback is no longer reached for these models. No public API change.Verification
Ran the rebuilt wasm streaming prepass headlessly on the affected models:
IfcSiteentity + forward-referenced site placement) — pins partial-index miss / full-index recovery; no external fixture.🤖 Generated with Claude Code