Independent .NET RVT reader - potential exchange of findings

[mahach666]

Hi!
I've been working independently on a similar project and recently published it as open source:
https://github.com/mahach666/RvtIO
It's a .NET library for reading RVT/RFA files without Revit or the Revit API, with element and parameter extraction, geometry decoding, and IFC2X3/JSON export. I've tested it against Revit 2020–2026 files.
I came across your project and noticed that we're tackling many of the same challenges, although with different approaches and technology stacks.
I also noticed some overlap with the areas you're still investigating, particularly parameter decoding and geometry reconstruction.
I thought it might be interesting to compare our findings and implementations. There may be things we've each figured out independently that could help the other project.
If you're interested, I'd be happy to exchange technical findings or compare results on the same sample models.
Great work on the research!

[mahach666]

I've also published a collection of IFC and JSON exports generated by RvtIO from sample Revit projects across multiple versions (2021–2027):

https://drive.google.com/drive/folders/1Qy0VcG07WJMcOYEQU3uaJvFvGuvP3C4U?usp=drive_link

These might be useful for inspecting the current output and identifying differences between our implementations.

[DrunkOnJava]

Hi @mahach666, thanks for sharing these examples and offering to compare notes! I really appreciate the work you’ve put into this.

For one of the examples, could you tell us where the original Revit model came from and whether it’s available to share? It would also help to know what permissions apply if we wanted to save or share the model and exports as test fixtures.

If you have a reference export for the same model, that could help us compare the results as well. Thanks again!

[mahach666]

Hi @DrunkOnJava !

These particular models are sample projects that Autodesk makes publicly available through its official resources and includes with Revit installations.

I've uploaded them to Google Drive so you wouldn't have to spend time collecting them yourself:

https://drive.google.com/drive/folders/1AAOM1ZJKaR1Nk9YP-LHr_H6LqD3kQ9Zx?usp=drive_link

As far as I know, these models are distributed under Autodesk's licensing terms. However, I wouldn't recommend adding them directly to a public GitHub repository without first verifying the redistribution rights.

Unfortunately, I can't share the other models I use for local testing and validation, as they are real-world projects provided to me under non-disclosure agreements (NDAs).

I hope that by combining our efforts and sharing our findings, we can significantly accelerate progress on both projects!

If you have any questions, ideas, or suggestions, please don't hesitate to reach out. I'd be happy to discuss them!

[DrunkOnJava]

Thanks for the details, and for RvtIO. On the models: we already run Autodesk's sample projects in CI, fetched from Autodesk's own download host for each run and never stored, so we won't use the Drive copies, which keeps us clear of the redistribution question you raised. Understood on the NDA projects.

On comparing findings: yes, gladly. What rvt-rs knows is in dated reports under reports/element-framing/, each measured against Revit's own IFC export of a model we can name. The two areas you mention are #155 (parameter-store wire formats and unit encodings) and #156 (sketch-to-solid geometry). If RvtIO has a finding there, the most useful form for us is the byte layout and the files you observed it on. Our clean-room policy (CLEANROOM.md) lets us build on published reverse-engineering work when we can say how a finding was reached (byte observation on files, RevitAPI.dll export names and the like), so we would ask that too. We would cite RvtIO and re-measure on our own corpus before anything lands.

For results on the same files: per-category element counts from RvtIO on Autodesk's samples would line up with what our Measure workflow reports per sample, and we can post ours for the same files.

[mahach666]

Hi!
Thanks, understood on the Drive copies and on clean-room. Everything below is built to fit that.

How each finding was reached. Only these sources: bytes of Revit files (including the class schema each file carries in Formats/Latest), output of the public Revit API (Revit 2022, on the Autodesk sample projects and on our own models), and the IFC specification. No disassembly or decompilation of any program or library, no output of any third-party converter. Each finding file states per claim whether it is VERIFIED (compared with an independent value), OBSERVED (bytes only) or UNKNOWN.

#155 (parameter store, ids, units): finding-parameters-and-units.md plus a standalone read-only probe (probe_parameters.py, Python standard library only) and its outputs. Byte layouts of the four typed value sets and how an element block is walked (859,650 of 859,700 blocks in 19 project files), the sign rule of parameter ids, resolving a shared parameter inside the file (29 of 29 against the API), extrusion and revolution parameter ids confirmed by building those elements through the API, unit factors, and the mm/25.4/12 vs mm/304.8 difference (the two forms differ for 57,067 of the integers 1..100000: by one ULP in 54,471 and by two ULP in 2,596; both forms occur in the same file). The layouts, block counts and the arithmetic reproduce from the folder with the public sample files; the comparisons with API output (29 of 29, the extrusion and revolution ids) do not, because the full API truth file and our synthetic models are not provided. Not established: blend ids, partial revolutions, formula objects. The PartAtom route did not reproduce (no GUID in it in the 24 sample families).

#156 (sketch to solid): finding-sketch-to-solid.md, probe_geometry.md, probe_gline_scan.py. Record layouts and class ids across 2021-2026 reproduce from the sample files. Volume comparisons rest on our own models, and the area comparison of the 105 hosts rests on API captures; neither is in the folder, so those parts you cannot reproduce from it, and the file says so. The sample files of this part are identified by sha256 in geometry_corpus.tsv; for 2022 there are two candidate sets (names with and without underscores) and which set was used was not recorded. The 149 library families that were read cannot be listed: the pick was random and its seed and file list were not kept.

Counts on the same files: counts.md, counts.csv (21 Autodesk samples, sha256 equal to your pinned list), ours_vs_theirs.csv next to the numbers in your committed reports. Table rows equal your ElemTable ids in 15 of 15 cells. Building-element totals and some IFC classes differ. Where we found a reason it is a difference of filter or mapping on our side (our building-element filter includes reinforcing bars and element assemblies: for rst_basic 817 - 346 - 16 - 1 = 454, equal to your number, which is our observation and not your published rule). The other differences are not explained (for example rac_basic 461 against 465 and 464, rac_advanced 5878 against 5657, IfcFurnishingElement 35 against 32); counts.md lists them. Neither side is called wrong. Two gaps of ours are listed (no IfcSpace for 2022 rac_basic, no IfcBuildingStorey for rst_basic). We would be glad to see your Measure numbers for the same files.

Also in the folder: geometry_corpus.tsv (sha256, size and pin status of the sample files of the geometry part), stored element bounding box (probe_bbox.py), the class schema across seven releases (finding-container-schema-header.md, probe_schema.py), README.md with status per finding.

Files: https://drive.google.com/drive/folders/1dS5LwAQgnQ579MzZP8pyY9ms6gZIU6xh?usp=sharing

Let me know if you needed the data in a different format, or if you have any questions!

[DrunkOnJava]

Thanks, @mahach666, and for the folder: the VERIFIED / OBSERVED / UNKNOWN marks, and the note on what can be re-run from it, made it easy to use. The write-up of what follows is RE-344 on PR #1442.

Sources. Everything that rests on bytes of the files, including the schema each file carries, fits our CLEANROOM.md. For the output of the Revit API our rule (the maintainer's decision of 2026-11-05) is that a published capture counts as published reverse-engineering work. We cite it and use it to know where to look. A value lands only when bytes of files our CI can fetch, together with Revit's own IFC export or the geometry Revit saved in the file, confirm it. A claim only the capture supports is recorded as reported, not measured. We use nothing that rests on NDA material. You say some of the models you test on are under NDA, and your volume and area comparisons rest on models and captures that are not in the folder, so we cite those and take no value from them. Your folder has no licence, so we restate facts with credit and copy none of your tables or prose. If you want any table committed here, please add a licence to the folder.

Already in rvt-rs. The four typed value sets and the family parameter slots (RE-207). The extrusion extents -1001800 and -1001801, and the sketch-to-loops stages with hole nesting (RE-327: all 6,172 extrusions of Autodesk's samples whose saved mesh decodes whole, 24 of 24 on the family corpus). The stored bounding box (RE-32). RE-310 had found independently, on 2024 to 2027 files, that no one conversion of millimetres reproduces the stored lengths. We infer, without having tested it, that the length entry RE-93 reads is your NamedParam slot and the text entry of RE-77 an item of your AString set.

Reproduced from bytes on our runners (Measure run 42039153578: 105 models, Revit 2015 to 2027, 1,284,631 element records). The samples are re-saves of one model per project, so counts of forms are form-and-file pairs. We also give them with files of identical form counts taken once.

• Arithmetic. Of the integers 1 to 100,000, n/25.4/12 differs from n/304.8 for 57,067 (54,471 by one unit in the last place, 2,596 by two).
• Sign rule. No positive id lacks a definition: 0 of 641,480, each the ElementId of a ParamElem* element of its own document. A negative id never has one, so only the positive side tests the rule. 4,818 records with no saved metadata are outside it.
• Stored lengths.
  • No one conversion explains them. mm × (1/304.8) leads on the family slots (69% to 93% of the values where seven conversions differ), as RE-310 found, and mm / 1000 / 0.3048 leads on the typed Double sets (58% and 59%).
  • The seven are not exhaustive. A chain mm/10 × (1/2.54) × (1/12) alone reproduces 7,413 and 6,195 typed values.
  • 17% and 21% of the typed values, and 4% to 26% of the slot values, match none of the seven. 66% to 76% of those are more than 3 units in the last place from every one.
  • The shares are alike on 2015 to 2023 and 2024 to 2027. That shows the stored bits survive re-saving, not that Revit's conversion is the same across releases.
• Revolutions.
  • -1001802 and -1001803 are held on 550 pairs, at most 207 counted once. Every value is a multiple of the 14-decimal 3.14159265358979, a truncation of π seven units in the last place below it, and that is where your 2π minus seven ULP comes from.
  • 517 pairs are 0 and twice that number. The others run from 0 to one such "π" (28), from half to one and a half (2), and from one to two (3). You had no partial revolution.
  • The first is below the second on every pair. None of the 555 nonzero values equals a multiple of π/2 by bits, so a comparison with π or 2π by bits fails on all of them.
• Blends and sweeps. 1,229 blend pairs hold -1001804 and -1001805. None of 5,006 sweep pairs (at most 1,383) holds any extent id.
• PartAtom. None of our 12 sample families holds a GUID in its PartAtom, as you found. They use no shared parameter, which is your finding file's reason. A public Revit 2014 family with shared parameters holds 2,800, as the id of each shared parameter's element: 25 distinct GUIDs on 25 names in 112 types.

Counts. Our numbers are Measure run 42028541274 (rvt-rs main at 5988d83). main has moved since and they are not re-measured. The figures of ours in your table were from an earlier head. Rooms now follow the export phase, and rac_basic's 14 return with #1435. Areas are written as spaces.

sample	RvtIO	rvt-rs	difference, by category
rac_basic 2022	455	450	3 Furniture Systems, 1 roof, 1 Mass
rac_basic 2023 to 2027	461	450	those, 4 mullions, 2 panels
rst_basic 2022	817	454	346 bars, 16 assemblies, 1 space (we write none on a 2022 file)
rst_basic 2024 to 2027	817	455	346 bars, 16 assemblies
rac_advanced 2021	5,878	5,657	192 panels, 25 Areas, 1 door, 1 assembly, 2 Masses
rac_advanced 2022	5,685	5,682	1 assembly, 2 Masses
rac_advanced 2023 to 2027	5,878	5,682	192 panels, 1 door, 1 assembly, 2 Masses

That is bookkeeping by category, not cause. We know the cause for the bars, assemblies and Furniture Systems (we do not read those categories, #1444) and for the spaces and Areas. We do not know it for the roof, the 192 panels, the door, or the 4 mullions and 2 panels (#1445). We read Masses and write one only where its own export value names an entity. Whether Revit's export writes them is not checked. Revit's one public export of rac_advanced (an IFC2X3 export by Revit 2021) holds 1,349 IfcPlate, 100 IfcDoor and no IfcElementAssembly, but it is of the 2020-era state, not of your 2021 and 2023 to 2027 files where you read 1,541 and 101. Your 2022 file reads 1,349 and 100, like ours.

What we cite as reported, not measured. The unit factors for specs we do not convert (mass density, specific heat, thermal conductivity, resistivity, permeability, stress, unit weight, the scale factors). That -1001802 and -1001803 are the start and end angle: the values are those of angles, with the first below the second on every pair, but we have not compared them with a mesh. The host-area comparisons, and the revolution and sweep volume rules. We take no name of a built-in parameter, only ids.

Questions.

1. You inflate each Partitions member with the previous member's last 32 KiB as a dictionary. We inflate each member alone and accept a group only when its CRC-32 and size verify. Is the dictionary load-bearing anywhere in RvtIO?
2. Your README says RvtIO's built-in name tables are re-verified against copies of Revit's resource DLLs, and your reply lists the sources as bytes of Revit files, the public API's output and the IFC specification. Could you say how the tables were produced, and which of those they come from? We take only ids from RvtIO and no names, so nothing of them is used meanwhile.
3. Could you list the ElementIds (the IFC Tag) of the 192 extra panels and the 1 extra door in your rac_advanced 2023 file, and of the 4 extra mullions and 2 panels in your rac_basic 2023 file? They would show whether those are placed elements with geometry in the file or something else you count.
4. Is a Structural Framing System an IfcElementAssembly in Revit's own export? The public rac_advanced export has none.

[mahach666]

Thanks for RE-344 and for clarifying the source and licence rules. Here are the answers to your four questions.

1. Inflate dictionary. The fallback exists in RvtIO, but I cannot show that it is load-bearing on these samples. I have now checked all 21 project files listed in counts.md: all 27,072 partition gzip members inflate independently with matching CRC-32 and ISIZE. None requires the preceding output as a dictionary. The check removes the paging segments first; probe_member_dictionary.py and the per-file results are attached.

My initial description confused the implementation's dictionary fallback with a demonstrated requirement of the files. The reader also has recovery paths that retain unverified output and mark it in its diagnostics, so it would be inaccurate to describe the whole reader as accepting output only after a successful trailer check. The standalone check above accepts a member only when both trailer values match.

2. Built-in name tables. These are maintained separately from the byte-level probes. They combine public Revit 2022 API enumeration identifiers with labels and definition metadata from Revit 2022 components. The embedded lookup tables themselves contain the labels.

The source list in my earlier reply referred to the findings and probes in the shared folder. Those probes do not load the built-in name tables. Keeping the comparison based on numeric ids works for this exchange.

Thank you for flagging this issue. We will begin reviewing and correcting the affected tables and their sourcing immediately.

3. Extra elements. The attached out/rac_advanced_2023_only_tags.tsv lists the 192 IfcPlate and one IfcDoor; out/rac_basic_2023_only_tags.tsv lists the four IfcMember and two IfcPlate. These are the tags present in our 2023 IFC and absent from our 2022 IFC for those classes. All 199 have an IFC object placement but no IFC representation. This establishes what our exporter writes, not whether the RVT contains saved geometry for them. We have no Revit IFC export of these 2023 files to settle whether Revit exports them.

4. Structural Framing System. We cannot confirm the mapping from Revit's own export. In our rac_advanced 2023 IFC, tag 201312 is the only IfcElementAssembly: PredefinedType BEAM_GRID, no representation, with 23 IfcBeam children linked through IfcRelAggregates. This is RvtIO's mapping, not an observation of Revit's exporter.

Files: https://drive.google.com/drive/folders/1bcC5YK09Npo-HgOQjIaytpok9i9xesjj?usp=sharing

[DrunkOnJava]

Thank you, that answers all four.

1. We inflate each member alone, and your 27,072 members on 21 files agree with that, so nothing changes here.

2. Thanks for being direct about this. We keep taking only numeric ids from RvtIO and no names, so nothing here is affected.

3. This helps with Are the 192 panels and 1 door of rac_advanced, and the 4 mullions and 2 panels of rac_basic, real elements we miss? #1445. All 199 having a placement and no representation means your IFC draws no body for them either. As you say, that doesn't settle whether the files hold saved geometry for them, or whether Revit's export writes them, since neither of us has a Revit export of those 2023 files. We record it there as your report, not as something we measured.

4. Noted as RvtIO's mapping. We write no IfcElementAssembly today (rvt-rs reads no reinforcing bars, element assemblies or Furniture Systems #1444), and would want Revit's own export before mapping one.

Griffin

[mahach666]

Thanks, Griffin. Understood on all points, and thanks for documenting the comparison. We’ll be sure to get back in touch if we find anything else that could help.

Best,
Ilia