On Land

Environment Information
At Rill Architects we run Archicad on macOS. If you work at Rill, this is your stuff. If you don't, but you work in Archicad, you may find something interesting. Anybody else, I don't know.

Adapted from my brief presentation at the DC Archicad User Group meeting earlier this month. If you want to look at the files, there is a download link at the end of the post.

Site Model

This is a simple scheme for using a single site model for multiple projects. It is applicable for everything from detached garages, to townhouse blocks, to proper campuses. The goals of this scheme are:

• Consistent 2D and 3D site data in each project, maintaining accurate story information.

• Visualization of the whole property in BIMx, while all buildings are easily kept up to date.

In our usage, the site is part of the main house's file. The site can be in a completely separate file using the same technique. The BIMx is published by the project file which contains the site. I will refer to the main house file and the small house file.


Alignment chart

I didn't want to talk this to death. What I like about alignment charts is they are assertive rather than argumentative. You have to just look at them and work out the relationships among the things, and ask yourself if your impressions of the things agree with the author's.

I made this by instinct. The strongest notion I had was that the morph tool is chaotic evil. The second strongest notion was that the mesh tool is a relic and needs to be done over. Then I was on my way.

Having meditated on it a bit, I think this is what the axes mean:

The lawful-chaotic axis runs from standard orderly content to custom content. The good-evil axis runs from user flexibility to user frustration. With that, I will proceed to talk it to death with some comments on each item.


Sheet A4-1
With the advent of graphic overrides, reflected ceiling plans are no longer a wilderness of tracing and weird hacks.

What shows:
• Walls
• Ceiling trim and finishes
• Ceiling fixtures including lights, fans, and mechanical fixtures
• Floor elements, including deck edges, stairs, counters

Using graphic override rules, floor elements are automatically shown dashed in RCP. And, ceiling elements, which are drawn dashed in the floor plan, are automatically shown solid. What a time to be alive.


Sheet A3-1
These are two detail-oriented drawing types that don't exactly go together, but they usually fit on one sheet. If there are too many assemblies or the schedules are very large, they can be separated.


This is the current state of element schedules. All projects will have schedules for windows, interior doors, and exterior doors. Many projects will have finish schedules, which are schedules of zones.

Let's quickly review the basics of interactive schedules. In the scheme settings, there are criteria, which determine what elements will be listed, and fields, which are the information to be shown about each element. Schemes can be imported and exported as XML files.

Then there is the schedule itself, where you control the column widths, header content, and text settings. It is pretty WYSIWYG with respect to output.

In addition to making schedule output, schedules can be used to inspect and edit model information. More on that later.



This started, as so many things do, with making a symbol fill for a tile pattern. A challenge of symbol fills is they need to tile (left and right meet, top and bottom meet, invisibly).

You can make new grid, running bond, and herringbone fill patterns by duplicating the extant ones and changing the dims. Anything more complex, you need to draw and work out the tiling.

That's just the fill pattern, which is vectorial, meaning you can use it in plan and surface fills in elevation. But you are on your own in 3D (OpenGL, BIMx). If you are delivering BIMx, you need to keep your textures in sync with your fills. Here is a simple way to do that.


All the common layouts (that we can think of) are blocked up in the project templates. These guidelines apply no matter when a layout is first needed.


These instructions are current as of Archicad 20.


You don't need to use clones to create views, but I recommend them. To review, a clone folder is a viewpoint set such as stories, sections, details, etc., with view settings pre-arranged so that when you make a new story, section, or detail, a new view is automatically created with the correct settings. View settings are easy to mess up and there are a lot of them, and they directly affect output. Better to set up clones in your template, and have all your views perfectly set, even for viewpoints that haven't been born yet.

Some users/managers/template makers eschew clones in favor of placing dummy sections (e.g.) and moving them around as needed. That's OK, especially if your projects are of a consistent scope that you can prepare the template for it. Our projects vary in size a lot, and I like the user-proofing aspect of clones either way.

The only thing I don't like about clones is that they always clone the entire set of viewpoints. We have two clones of the sections: one for building sections at 48 scale, and one for wall sections at 16 scale. Both clones contain all the sections, so we sort the list using the section ID. Building sections are A2 and wall sections are A3, and then in each folder the user has to mentally tune out the sections that shouldn't exist. (And the junk sections, which are never used for output, appear uselessly in both.)

Junk trimmed for brevity

I'd like to see clones that could be filtered by ID, so that only the A2 sections appear in the building sections clone, and only the A3 sections appear in the wall sections, and the junk can be avoided completely.

ID clones

I made a quick but not completely disposable scripted object. Probably 30-45 minutes of work. I saved it in the embedded library of a scratch file, rather than in a live server folder where someone might notice it before it's done. (The odds of this are crazy low, plus it's no big deal, but that's what I did.) The scratch file is Archicad 20, because we haven't officially migrated, but my projects are in 21.

Then the standard procedure is to save the object out in Library Manager, and delete it from the embedded library so the scratch file doesn't have a duplicate.

Then, reload libraries in the real project so the new object can be seen.

Upon reloading, I had several duplicates. Inspection revealed I had exported the whole embedded library from the scratch file. (The two files have some deprecated labels in common.) I had clicked the save button without highlighting the single object.

That's the kind of thing I like to fix right away, so I went to the Finder and found the stupid 'Embedded Library' folder inside '22 Plumbing' and deleted it. Because this folder was on a server volume, the deletion was immediate - such things don't go to the trash. (I still miss this from OS9.)

Then I went back to the scratch file to export the object properly. But since my procedure is to delete the object right after saving it, it was already gone.

It's gone from the embedded library, and the server copy was deleted along with the stupid folder. Maybe it still exists in the actual project, since I hadn't reloaded there yet. Alas, no, because while the object still appears in the settings dialog, it doesn't work at all because the file on disk is missing. I also tried crashing the scratch file's Archicad instance in hopes the autosave data might remember the object. Alas, no, again.

So that is how I managed to completely delete a new object. The only hope would be if Time Machine or Backblaze had run during the few minutes between saving the embedded library folder and deleting it. The odds of that are also low, and it didn't happen.

It's frustrating to lose work, but it wasn't a lot. Between automatic backups and autosave, it's difficult (knock wood) to lose a lot of work in Archicad. Autosave for objects would be nice, but it wouldn't have helped in this case. While I've been at this a long time, I still find new mistakes to learn from.