Repository navigation
v0.12.0 vs v0.6.1: some meshes export as bounding boxes; some doors as IfcOpeningElement #1247
Description
Both versions built plain from their release tags (no patches), 49 of our own files, counts only.
Linux, 16 GB container. Elements are matched by Revit element id between the two versions.
1. Real meshes become 12-triangle boxes. On 9 of the 49 files, 665 elements that v0.6.1
exports with a real mesh come out of v0.12.0 as a 12-triangle bounding box. Most are beams (341
of them in one 142 MB Revit 2024 file); the rest are railings, light fixtures, doors and generic
models. Example: one light fixture goes from 18,944 triangles to 12. On 598 of the 665 the box
also differs from v0.6.1's mesh bounds by more than 0.5 mm.
2. Some doors exported as openings. On a 438 MB Revit 2024 file, rvt-ifc --large-model
writes 73 door instances as IfcOpeningElement instead of IfcDoor. Their family names all
start with AR_DOR_. The other 361 doors in the file come out as IfcDoor.
On the plus side, v0.12.0 reads 16 of these files that v0.6.1 cannot read at all, and it is
faster on most files both versions read (one 202 MB file: 135 s to 35 s).
Happy to run a candidate fix on these files and report counts.
Activity
research(elements): the RE-298 probe prints each type's native geomet…
research(elements): the unset-map door probe is RE-299, RE-298 being …
DrunkOnJava commentedon Nov 2, 2026
Thank you for running these comparisons and sharing such detailed results while keeping your project files private. I’m investigating both the mesh and door behavior, and I’ll follow up here with what the comparisons show. I really appreciate the time and care you put into the report.
fix(elements): a door or window whose type's native map holds entries…
docs: RE-299's addendum to the reconnaissance (#1247)
ci(measure): the Compare summary leaves kept IFCs out of its text dif…
docs(saved-graphics): RE-301's report and changelog entry for left-ha…
fix(saved-graphics): a GImposter, a light source with no surface, no …
fix(elements): a type whose map is all unset and whose family shows n…
38 remaining items
research(saved-graphics): a cylinder face trimmed by several loops dr…
chore(release): prepare v0.12.2 (#1269)
DrunkOnJava commentedon Nov 3, 2026
v0.12.2 is out and includes all four fixes from
candidate/1247-b, so there's no need to build the branch:pip install -U rvt,cargo install rvt --lockedor the archives on the release page install it. The same two counts for your beams would still help, since their cause is still open: how many carry eachBodySourcevalue in the exported IFC'sRvtElementRecordGeometryproperty set, and the linervt-ifcprints about saved graphics. Thank you!docs: 0.12.2 is the published release, each channel checked from what…
hemanth1986 commentedon Nov 3, 2026
Thanks! Results for 3913319 (
candidate/1247-b) against v0.12.0, same 49 files and flags,counts only.
Boxes: 665 → 560. No new box cases in any other file, and element counts match v0.12.0
everywhere. 26 files gained triangles.
The 341 beams: all 341 carry
BodySource=partition_element_record_bbox, with orwithout
--saved-meshes. With--saved-meshes, rvt-ifc reports 256 of 930 bbox bodies drawnfrom saved graphics and 674 kept their box; none of the 256 are among the beams.
Doors (438 MB file): with
--large-modelthe candidate still writes all 73 asIfcOpeningElement(0 asIfcDoor). rvt-ifc prints "saved graphics not read, bodiesunchanged: reassembled group budget exceeded". The probe as given finds 0 rows, since it opens
at default limits. In a local copy switched to large-model limits, all 73 doors match but show
u, with "type records not read" and "group budget exceeded". So on this file the group budgetstops us before the door type is read, even with
--large-model.fix(native): the changelog fragment for the group budget and door evi…
fix(native): a walk's group budget is no more than its partition's in…
research(elements): the beam probe matches the export's IFCBEAM spell…
fix(native): --large-model raises the native reads' group budget, and…
DrunkOnJava commentedon Nov 3, 2026
Thank you, that narrows both down.
Doors: you found the cause. Every read of native records took a fixed 256 MiB budget for one reassembled group, and
--large-modeldid not raise it. #1271, now onmain, makes--large-modelraise it, and a door is no longer written as its opening alone when its type could not be read. Could you runmain(3ba5bda or later) with--large-modelon the 438 MB file, and say how many of the 73 come out asIfcDoorand whether rvt-ifc still prints "group budget exceeded"?Beams: a beam keeps its box when its element data holds no location line, when the line it holds does not fit its record box, or when its stored copies in different partitions hold different lines (a rule v0.6.1 already had). Commit cd3aff0 (branch
research/1247-beam-probe, which also has the door fix) adds a probe that sorts the boxed beams by which of these keeps each one:cargo run --profile ci -p rvt-probes --example probe_re306_beam_copies -- model.rvt. It opens the file with--large-model's limits, and itsstreams_not_readline says whether any part still could not be read. It prints counts only, no ids or names. Itscensusanddisagreelines for the beam file would tell us which it is.Thanks again!
feat(diagnostics): the unread-type warning is left out of placeholder…
research(elements): the beam probe opens with --large-model's limits …
feat(diagnostics): the export diagnostics count the doors and windows…
research(elements): the RE-306 report and probe say the copies rule p…
research(elements): RE-306, why a beam keeps its record box: one line…