gbXML from adjacent conceptual mass/adjacent space missing 'small' surface

[RIPENG]

It seems that when gbXML is exported from adjacent conceptual masses/adjacent spaces there is a 'small' surface tolerance in Revit 2021.1.3 such that a gbXML surface is not exported if it falls under an area tolerance. Please see below for an example of an exported conceptual mass and space gbXML with missing 'small' surface.

Adjace mass missing surface

Adjacent space missing surface

The example above is typical of gbXML InteriorFloor/Ceiling surfaces in multi-story buildings where adjacent conceptual masses/adjacent spaces between floors interact in ways that result in 'small' surfaces. The parent Revit file and exported gbXML are attached for examination. Please note, both gbXML were exported with 'Analytical Space Resolution' and 'Analytical Surface Resolution' set at the 0'-6" minimum allowed by the 'Energy Settings' GUI.

In searching the Revit 2021.1 API it is not clear whether or not it is possible to alter Energy Settings to more reliably capture adjacent conceptual mass/space 'small' surfaces in exported gbXML. Any guidance the community may be able to offer to capture adjacent conceptual mass/space 'small' surfaces in exported gbXML would be appreciated.

-Jake

[jeremy_tammik]

Yes, I have heard of similar issues in the past. Interesting topic. Apparently, they need to be expected and gracefully handled by post-processing. Sorry about that. My favourite approach is to approximate all floating-point vertices by integer-based coordinates rounded to the closest millimetre as soon as possible in the process. That removes all downstream floating-point and rounding issues, reduces data size, speeds up calculations and makes human-readable data more legible. How big are the small discrepancies? Smaller than one mm? Of course, you could increase the rounding to fit your needs, to the closest 5 mm or 1 cm or so. Of course, in this case, the initial gbXML data is floating-point, so you would have to post-process that intelligently to be able to make use of the Revit gbXML functionality at all. Looking forward to other suggestions and experiences from the rest of the community.

[RIPENG]

---

@jeremy_tammik wrote:

Apparently, they need to be expected and gracefully handled by post-processing.

---

Interesting. I suppose it's a good thing that Revit leaves out 'small' surfaces in a detectable way. Still, a post-processing requirement is a surprise given that Revit sits on top of a serious modeling kernel. Hard to envision how a foreign environment would handle the problem more gracefully than the native environment.

The first question that comes to mind to bound the post-processing problem: what are the limits of Revit 'small' surface.

---

@jeremy_tammik wrote:

How big are the small discrepancies?

---

In the given example the missing 'small' surface is ~2.5 inches wide x ~18.6 inches long (~0.3 sqft).

I must admit, I don't have a good handle on industry gbXML performance requirements. I have heard/seen comments like, 'we quickly found out that watertight gbXML is not a thing.' Beyond that I have not seen deliberate statements about gbXML performance requirements. ASHRAE RP-1810 was recently completed but the report does not address concepts like missing 'small' surfaces.

-Jake

[RIPENG]

xgbxml has Shapely dependency. It looks like Shapely has enough geometry guts to look for missing 'small' surfaces and make replacements.

The basic idea:

1. Make 'floor' surface based on gbxml space 'wall' geometry,

2. Union existing gbxml space 'floor' geometry,

3. Difference made 'floor' and existing 'floor' geometry,

4. Turn remainder geometry into missing 'small' surface replacements,

5. Insert replacements into gbxml.

-Jake

[jeremy_tammik]

Thank you for the very cool pointer. Shapely looks like a great library! Added it to the blog:

https://thebuildingcoder.typepad.com/blog/2023/09/element-diff-compare-shapely-and-rdbe.html#4

[RIPENG]

Sure thing. Thank you for taking an interest.

I'm happy to report Shapely was able to find a missing 'small' surface (hole) in the 'Mass' demo file attached to this thread.

To find xy plane holes:

1. Make Space surface polygons with shapely.Polygon,

2. Make Space polygons from Space surface polygons with shapely.union_all,

3. Make Level surface polygons from Space polygons with shapely.union_all,

4. Ask shapely for the 'interiors' attribute for a sequence of rings which bound all existing holes in Level surface polygons.

Next step is to correlate holes with Spaces. This is the trickier part in my opinion. Going in plan is to use polygons as defined by Space wall outlines as truth data. Not sure how this will mesh with current Ripcord Engineering gbxml workflow. Time will tell.

-Jake

[jeremy_tammik]

Wow, brilliant! Thank you very much for the confirmation and good result. I added it to the post right away:

https://thebuildingcoder.typepad.com/blog/2023/09/element-diff-compare-shapely-and-rdbe.html#4.1

[RIPENG]

Ripcord's method was a fair start at resolving the problem but the author of the xgbxml library, Dr. Steven Firth of Loughborough University, took it to another level with a new method called get_gaps_in_surfaces. As Dr. Firth puts it:

"The gbxml_functions. get_gaps_in_Surfaces_of_Space does two difference calculations (one the reverse of the other) and combines the results, which is the equivalent of a symmetric difference."

What this means in practice is that the method finds interior as well as exterior gaps without regard to surface type. The method also identifies space adjacency and determines geometry. The attached pdf example by Dr. Firth demonstrates how the method works in concert with other xgbxml methods to (1) find gaps and (2) insert gap geometry as surfaces into an existing gbXML. While xgbxml is not to a point where it will fill in all relevant surface attributes automagically, it does take the lion's share of manual data entry off the end user's plate.

In keeping with the concept of operations that it is best to adjust a model to correct gbXML output rather than correct gbXML output of a model that needs adjustment, Ripcord's intent is to use get_gaps_in_surfaces as a model tuning tool first and as a gbXML correction tool as a last resort. Ultimately the goal is to determine how far out gbXML can be in terms of gaps without causing problems for building performance tools with an EnergyPlus back end.

-Jake

[jeremy_tammik]

Wow. Huge wow! That is extremely powerful functionality. I heard of several tools for fixing gaps in surfaces and solids,  but I never saw anything as accessible as this. Thank you for the brilliant solution and beautiful documentation. I will be overjoyed to add that to the blog as well, if I may, and I am certain that many people will be very thankful for it. So many steps, each of them impressive in itself:

• Parse and interpret gbXML model
• Render graphically and plot
• Find, document and fix gaps
• Update and store fixed gbXML

[RIPENG]

Couldn't agree more about the power of xgbxml in general and for development of custom workflow to compensate for Revit's gbXML limitations in particular.

Thanks for your kind recognition. Got to say Dr. Firth is the wizard behind the curtain who makes it all look so easy. By and large Ripcord is a grateful end user. For those curious about the geometry side of the problem, there is plenty of magic to be found in the geometry_functions portion of the library.

Please feel free to add to the blog. As always, thanks for your interest and support.

-Jake

[jeremy_tammik]

Done:

https://thebuildingcoder.typepad.com/blog/2023/10/xgbxml-fixes-building-geometry-gaps.html#2

Thank you so much for sharing this!

[RIPENG]

Thanks for taking the time to build the blog post. Very nice!

From the blog post:

'Many developers have encountered issues with gaps in the building geometry caused by the relatively low precision used by Revit when tessellating surfaces.'

Based on experience over time at Ripcord, 'low precision' appears directly related to an area threshold rather than a length threshold. What might be considered 'sliver' surfaces export OK. But once 'sliver' surfaces fall under the area threshold, whatever it is, the surface is not exported.

It is likely that direct control of the area threshold would offer operators relief. Inability to control the area threshold creates a level of operator compensation that likely compels most to abandon value added analytical tasks.

-Jake 

[jeremy_tammik]

Thank you for your appreciation and additional info. That sounds useful too, so  went ahead and added it to the post as well:

• https://thebuildingcoder.typepad.com/blog/2023/10/xgbxml-fixes-building-geometry-gaps.html#2.9