2 weeks ago
I recently published a detailed comparison of Archicad and Revit as professional-grade BIM platforms — examining their underlying logics (object-oriented vs. database-driven), computational performance, consultant ecosystem compatibility, and how the choice impacts architectural practice strategy in 2026.
Curious to hear how others in the community are navigating this choice — especially those who've worked in both environments.
2 weeks ago - last edited 2 weeks ago
A very interesting read. Maybe felt a little Archicad biased maybe, (just to play devils advocate, given I am also heavily Archicad biased.) So interested to hear what Revit users take on this article.
I totally agree the ability to ‘design’ in the software, especially in 3D is such a big advantage of Archicad.
My biggest frustrations with Archicad are:
- the 2D performance, I was always under the understanding that this is still on a single core process.
- the difficulty managing the room layout plans for a portion of the floorplan. Worksheets and not viable. The cropped floorplan view ability in Revit is very attractive.
- GDL, while powerful, is totally inaccessible for everyday users compared to creating Revit families.
That said, the dominance of Autodesk promoting themselves as the defacto AEC solution is troubling and frustrating, and especially in the Australia market, means Archicad gets a bad reputation as being unfit for any architectural work beyond residential, when i don’t believe is true. And the negative aspects of Revit are just accepted as what you have to live with.
2 weeks ago
Hi Scott,
these are three genuinely sharp points - I'll try to put my thoughts towards each.
On 2D plan performance being single-core: You are correct. Archicad's 2D plan window is primarily single-threaded and frequency-bound to a single core - Graphisoft acknowledge this, and their own hardware guidance consistently prioritizes clock speed over core count for this reason. The multi-threading they have implemented - Predictive Background Processing for sections, elevations, and 3D view generation - is real, and 2D rendering of projected 3D elements does get some multi-core treatment. But the plan window itself is largely single-threaded, and that is a genuine architectural limitation. The main practical levers are keeping Embedded Library size lean, minimizing Solid Element Operations, and managing linked file complexity - but those are mitigation, not a fix for the underlying constraint.
On partial floorplans: I respectfully push back here - not on your frustration, but on the conclusion that there is no viable workflow. My approach: clone the floor plan in the View Map, set it to the enlarged scale, assign a layer combination built specifically for that drawing type (construction detail layers, specific annotations, nothing else), and a dedicated pen set tuned for that scale. Placed on the layout and cropped to the relevant area, it is fully live - updates with every model change, and can sit on multiple layouts at different crops simultaneously. The advantage over a Revit cropped region is that each cloned view has fully independent display settings, not just a spatial crop of the same representation. It requires deliberate upfront setup, but once the View Map is structured for a project, it is genuinely powerful.
On GDL accessibility: Agreed without qualification. GDL's learning curve is not reasonable to impose on everyday users, and Revit's Family Editor is more visual and more accessible for most content creation tasks. The technical trade-off is worth understanding: GDL is essentially a BASIC-derived scripting language - branching, conditionals, external data references - with objects typically under 20KB against significantly larger Revit family files, because GDL stores only a mathematical reference rather than embedded geometry per instance. The power ceiling is higher in GDL; the floor is much harder to reach. Revit also has a vastly larger manufacturer content ecosystem, which is a real day-to-day advantage that no technical argument about GDL's power cancels out. However the kind of flexibility I feel during design when editing those archicad native library objects, is phenomenal as compared to the families in Revit. It would be great if Graphisoft is able to create Autodesk-like object ecosystem.
Your observation about Autodesk's market dominance creating unfair perception problems for Archicad rings very true from the Indian market too - the negatives of Revit get normalised while Archicad's real capabilities stay invisible to firms who have never seriously used it. Conversations like this one are part of how that changes.
2 weeks ago
Thanks for your comprehensive response, just a follow up on the isolated room layout plans. What you’ve described is what we also do, but the hurdle comes when you need to visually isolate an individual room, and have notation, labels and dimensions surrounding just that room, and the annotation for that room then has to sit over the top of the surrounding rooms. This is a big problem on health projects with very deep floor plates, and AusHealthFacilitiesGuidlines require every individual room to be laid out on an individual sheet.
Our current workaround is masking fills and annotation on different layers for every second room. But it becomes very convoluted for 200+ rooms.
2 weeks ago - last edited 2 weeks ago
I agree. I faced similar challenges and worked around it by limiting graphical annotation - using labels (for live element and material property retrieval) and keynotes (for directives and instructions), with the detail pushed into keynote legends and zone-based schedules. It kept the plan clean enough to manage.
For your specific need - individual rooms on individual sheets with full annotation - I researched this thoroughly (aided by Claude) and found no single robust native answer. Summarizing the findings:
1. Annotation Layer Strategy (This, I think, you are already using): One dedicated annotation layer per room (e.g., ANNO-FL01-RM-101), with a matching Layer Combination per room that shows structure plus only that room's annotation layer. A saved Marquee clips geometry at the room boundary; the Layer Combination kills annotation bleed. Fully live-linked - dimensions update, labels stay associated. The cost: 200 rooms means 200 layers, 200 Layer Combinations, 200 Views, plus strict annotation discipline from everyone in the file.
2. Worksheets / Details (I am not using this, as I like dynamic updates with no manual intervention needed): Both create hermetically sealed 2D drafting spaces - neighboring room annotation physically cannot exist there. Bleed eliminated. However, nothing inside is live-linked: dimensions measure static 2D geometry, associated labels cannot exist (no model elements present), zone stamps freeze at paste time. Trace & Reference shows the current model as a ghost for visual reconciliation, but you resync manually. Workable in documentation phase when design is frozen; genuinely painful during active design.
3. Labels, Keynotes, and Zone-based Schedules (I am now using this workflow personally): Rather than fighting annotation bleed, reduce what's on the plan in the first place. Labels retrieve live data directly from elements and materials - compact, element-bound, less prone to crossing room boundaries. Keynotes handle directives and instructions as small numbered flags, with content living in legends and schedules off the geometry. Related Zone Name and Conflicting Zones properties in Interactive Schedules then deliver the full per-room technical breakdown - finishes, elements, areas - live from the model. For AusHealthFacilitiesGuidelines Room Data Sheets specifically, this aligns well since the format is already largely tabular.
4. python-archicad Automation (Claude's suggestion - not personally implemented): Graphisoft's open-source Python library communicates directly with a running Archicad instance and can batch-create the entire annotation layer structure, Layer Combinations, Views, and Layouts from zone polygon data - turning days of manual setup into a script run. Documenting it here as a viable path for technically inclined practices, though I cannot vouch for it from personal experience.