Seed geometry workflow

[jpstaub]

Hello,

I found Gingerbread through this paper which I read with interest since I have been working on the same general problem of accurate gbXML production.

Through trial and error the following workflow was developed to create accurate seed geometry for consumption by Revit to export accurate gbXML:

Use Model Lines to outline exterior of background - Manual work
Use Space Separation Lines to partition interior volume - Manual work
Create exterior boundary w/buildiing elements - Dynamo automated & Manual work
    +Wall Width >> 1/2 Nominal Width
        -Matches Mass family exterior boundary to Space exterior boundary
    +Wall Location Line >> Finish Face: Exterior
    +Floor >> Bottom floor only
    +Roof
    +Windows >> As required
Place Spaces - Revit automated work
    +Upper Limit >> By level
Transform Spaces into Mass families - Dynamo automated work
Place Mass families - Dynamo automated work
Set Mass family instance 'Mass Floor' - Manual work
Export gbXML using Conceptual Masses and 0% Glazing (File A) - Manual work
    +Solid Conceptual Mass based geometry & boundary conditions captured
Set Exterior Walls to nominal thickness - Manual work
Export gbXML using Space Volumes (File B) - Manual work
    +Space based geometry & openings captured
Merge File A and File B - Automated work
    +Solids based geometry, boundary conditions & openings >> high accuracy

I am currently working on an automated method to merge the Openings data in File B with the data in File A.

Because you have direct experience with gbXML, what would you recommend to automate the merging of Openings data in File B with the data in File A?

Best wishes, Jake Staub

[ian-quinn]

Hi Jake:smile: what a coincidence I just saw gbXML official tweet about your project. I've tested your code and the workflow is quite elegant to me. The overall idea, I presume, is to extract the openings from a space-based gbXML, then merge them into a mass-based gbXML, thus avoiding shattered geometries. Right? But not to compare and merge two gbXML files on the geometric level, like joining a tower with some podiums (OpenStudio has done something like this). There are many steps in the workflow including manual/automated modeling by Revit/Dynamo/Tkinter, and it's hard to automate it by not knowing your targeting problem.

It seems to me that the current python code transplants the Opening coordinates under a new parent Surface (retrieved by comparing the serialized coordinates). This may not tolerant to some modeling flaws because 1. the coordinates of such two versions of the surface may slightly offset and the sequence may be reversed. 2. opening may have a collision with its parent geometry. It's not a big deal if the Revit model is manually perfected, but if we've already poured in that much labor why not use Revit's gbXML output by Room? The workflow of Gingerbread is simple as well, appending the opening to the nearest surface, then merging/trimming the openings within the same surface. I may suggest the workflow deserialize the gbXML and manipulate the geometry in its own environment. Just to flatten the openings and their hosting surface to a 2D problem then apply a reverse transformation. Python package Shapely will help. After all these, serialize it. However, it depends on what problem you've encountered in real projects. More robust, more complex.

Sorry for the late reply. I just came back to work on this repo.

[jpstaub]

No worries. thanks for the reply. I appreciate it.

The overall idea, I presume, is to extract the openings from a space-based gbXML, then merge them into a mass-based gbXML, thus avoiding shattered geometries.

Your statement above captures the intent. In addition to shattered geometries, unexpected surfaces and incorrectly assigned surface types have also been observed regularly in real world Space based Revit gbXML. These behaviors have not been observed in Mass based Revit gbXML presumably because Revit translates Mass geometric data directly whereas geometric data is inferred from Rooms and Spaces for translation. Revit geometric data inference from Rooms and Spaces for translation generates an gbXML error rate that is unmanageable for all but simple shoe box models. That said, Space based Revit gbXML does accurately capture detailed Window elements hosted in exterior Walls whereas Mass based Revit gbXML cannot capture detailed Window elements.

The end result is a requirement to blend the accuracy of Mass based gbXML with Window data in Space based gbXML. The merge of Mass and Space based gbXML results in an accurate representation of the building problem with low error rate.

Good observation regarding the current Opening Surface matching scheme in gbxmlMerge. Because it is based on matching a single point between Surfaces it is delicate as you observed. Thanks for the guidance on Opening Surface matching. Makes sense to simplify the problem to 2D for detection purposes.

Finally, how does gingerbread write gbXML? Does it use the Revit API or does it make use of an gbXML library of some sort? I found a nice python library to query gbXML but there's not much out there beyond the OpenStudio forward translator, which has problems of its own, to write gbXML.

Best wishes, Jake

[ian-quinn]

Exactly, what you said about gbXML (by Revit). It seems that we are on the same path. The exchange format, gbXML, has never been considered by BIM modelers (and it is complicated to perfect it with Revit for energy simulation purposes). Maybe it is because of the nascent BIM market, full of chaos. At the start, I tried fixing the Revit model by scripts, but it still couldn't guarantee a flawless gbXML export, so I abandoned the built-in gbXML tool of Revit and turned to reconstruction, bypassing all modeling flaws. As you see, Gingerbread is not yummy for all the bugs and limitations. The merging operation like yours may be a good solution under the framework of Revit, on condition that the room/space volume is carefully defined.

About writing gbXML, since the .NET framework offers a built-in serializer and deserializer for XML, you just need to provide a class file defining the hierarchy of the gbXML schema. Check this: gbXMLReadWriteSDK_CSharp. Sort of a benefit of C#. According to README, building-energy/gbxml only queries the content, which may not help. I'm not aware of other python packages that handle gbXML specifically... ElementTree could be the last resort. I've never tried OpenStudio forward/reverse translator, but I do spot some bugs in assigning boundary conditions as well.

I think it's okay to pack your workflow within Dynamo or a Revit Plugin. However, Dynamo is just a sandbox to demonstrate your workflow. If you feel tied down, manipulate the model with RevitAPI (C#/VB/C++) directly. Good luck :tada:

[jpstaub]

I finished up the gbxmlMerge utility with the assistance of xgbxml and topologicpy.

xgbxml allowed for API based gbxml handling.

topologicpy allowed for robust geometry testing to determine opening destinations without 2D simplification.

gbxmlMerge was recently exposed to a production model and it performed well. Looking forward to additional operational testing.

-Jake