Last week, at the launch of ARCHICAD 23 in Hong Kong, I had the opportunity to present some workflows and tools that we’ve been developing to improve 2D CAD files exported from BIM.
This workflow been an ongoing internal R&D Project that started with a simple problem.
Problem :
DWGs Exported from BIM Tools are difficult to work with.
This is a common statement we’ve encountered on our own projects and in some consulting projects we’ve done for other design studios where the client or other consultants aren’t very happy with the DWGs exported from ARCHICAD and BIM in general.
First things first, we had to understand what this statement means. From previous experience and investigation, we understood that the DWGs exported from Archicad don’t behave like they would if they were drafted by a Native Autocad User.
ARCHICAD treats each wall as an individual 3D entity so when it creates DWGs from these entities, they are each treated separately, this leads to each wall having its own boundary and its own hatch that are not combined together.
What this means is that :
– Polylines or Polycurves are exploded into single lines and curves
– Hatches are broken up and subdivided
– Blocks are dead, meaning they don’t have functionality. If you change one instance of the block, the others wouldn’t automatically change
Once we understood the problem, we could start finding a solution. Since we’ve been working with Rhino for some time and it works well with DWGs, our first approach was to create a Grasshopper Script inside Rhino that could look into the block structure and work with the metadata from the blocks to rebuild the walls. We use the Elefront Plugin developed by Ramon van der Heijden and Alan Tai from Front Inc for block management.
We go into the block structure, deconstructing them recursively into the following types : Curves, Hatches and Blocks.
We then use the Hatches to rebuild their boundaries keeping the layer structure intact. Then we Boolean these boundaries together to create clean polylines or polycurves and rebuild the hatches.
At the same time, we use curves from the blocks and the newly rebuilt boundaries to identify which lines were projected.
Simultaneously, we’re looking for blocks that define windows and doors, find identical blocks and replace them with a single instance
Everything is then baked into the correct layers while the geometry in the original layers is deleted.
We tested this solution with various files understanding what’s working and what isn’t. Once we were happy with the performance of this Grasshopper Script, it was time to move on to the next issue – Automating this process for multiple drawings.
Since this solution is to process DWGs, it doesn’t make sense to do this manually for each drawing as some of our drawing submissions could be hundreds of different files. Manually doing this for hundreds of drawings would take hours of repetitive work with high chances of errors.
This is where we had to take a deep dive into the world of Python.
Programming in python gave us several advantages:
– Python interfaces very well with Grasshopper
– We could create a simple User Interface (UI) which meant that anyone could run this process without any knowledge of what is going on under the hood
– We could keep track of the state of the process by passing certain booleans to know how many files, have been processed, what stage in the process we’re currently at, etc.
For all the nerds (like myself) out there who want to know what is happening inside python, the invocation chain of commands basically runs like this :
We have 2 methods : Setup and Run
> Setup runs once and initializes our User Interface and gets information like paths to input and output folders, which layers they want to process, etc. and stores variables like Layer Names and their corresponding Colours.
> Run is executed for each file in the folder and invokes a chain of commands that opens each file, prepares it for the Grasshopper Script by Purging out unnecessary information, Passes Layer Names to the GH Script, Runs the Script and checks that the layer names and colours are correct and exports the DWG
This resulting hybrid workflow has allowed us to process DWGs that perform how we’d like them to, as if they were drafted on Autocad by a native Autocad User. They’re made actual polylines and polycurves, hatches that are uniform and blocks that are functional.
By solving this problem for ourselves in a way that is dynamic, this workflow is a pseudo-plugin for Rhino that can be customized to fit the needs of our various clients that consult us for BIM workflows.
Although, in 2019, there is an intent to move away from Autocad and into more high dimensional file exchange systems like IFC models, the reality is that a lot of offices or project consultants still require and work on Autocad. We’re just trying to streamline this process for ourselves and our clients to extend functionality of our DWGs using this workflow.
If you have any questions or suggestions about this workflow, or you would like to work with us to see how we can implement this for you, feel free to reach out to me at hello@weareenzyme.com
