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.


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.

Jetty panorama


I am a Field Notes fan. They make awesome versions of a completely ordinary product: disposable pocket size notebooks of the type that would be given out as marketing by midwest farm/feed and hardware shops in the mid to late-mid 20th century. They make books in a different style every 3 months. If you subscribe, you get the new designs each season along with surprises. This May, a surprise was, they made a final exam type 'blue book', which you may remember from some phase of school.


I went to a preppy middle/high school for some years and my earliest memory of these books is from 8th or 9th grade.

Along with the books, which are 3x better executed than any blue book I have ever seen in the wild, comes a challenge/assignment/contest:

"Using one of the enclosed Blue Books, please submit a written essay relating a notable dramatic or humorous event that happened while you were in elementary or high school." And they list grading criteria including penmanship (in all caps), which I blame for my loss.

As we used to say in architecture school, I went around the program. This is not a memorable story from whenever, but it is a good idea IMO, and when you have an idea you should follow through with it. It is below the fold, and yes I wrote this out longhand and put it in an envelope with a stamp.


In Archicad 21 you can use autotexts in labels. Rather than describing an element in disconnected words, you can display the actual properties, attributes, dimensions, etc. of the element. Use Archicad properties and name your building materials, surfaces, and composites carefully, and you can get good automatic notes. GDL-scripted labels have long been able to do this, but it's an order of magnitude more convenient to have this built into the basic text label.

Generally, such associated annotations are better, because if anything changes in the elements the annotations change too. Think ordinary dimensions. An element and its associated annotations are one thing.

But my goodness they botched this for US users.

If you use (feet and) fractional inches for your dimension units, you can't use any dimensional autotexts in labels without looking like a hack. This is because autotext dimensions are formatted according to the calculation units preference rather than the dimension units. There are no fractional length unit options in the calculation units preferences.

Here are two simple dimension values. The wall thickness is a dimension and the fixture elevation is a label autotext. Archicad says with a straight face that one of them is a dimension and the other is a calculation. A calculation with no operators and a single term, apparently.

Doesn't everybody vary units within drawings? No, no one does.

Wait, here's a label that works.

This is the Archicad library's Elevation Label 21, a scripted label (no autotext) that has been available for years. (Like a lot of Archicad library parts, this label over-serves and you have to fiddle a lot to get it looking right, but it's functional and reliable.)

That's not so hard, is it?

This label is scripted to use the dimension units, as common sense would dictate. There are global variables for the calculation units too, so they could have this label use them, but it's not even an option, because that would be (is) ridiculous. If I wanted decimal units, I could just set the dimension standard that way.

Maybe in Archicad 22 they'll fix the Elevation Label to use the calculation units for consistency. (KIDDING!)

I don't know how this decision made it out of committee, and I'm sorry I didn't notice it earlier, but that usually doesn't matter. This is worse than How Could This Possibly Be What I Want, it's just carelessness that never got reviewed because it doesn't affect metric users. (But it's wrong there too.)

Why don't I care about the reason?

Because I'm a user, not a developer. My job is to make my projects work, and the developers job is to make the program work. I'm sure there's a reason for this situation, and it might be very interesting from a development point of view, but that's not my point of view. To a user, it's just wrong and needs to be fixed. (In all honesty, as an Archicad observer I'm curious about the reason, but it's not the user's role to care.)

And, the whole dimension and calculation units thing probably needs a do-over. It would be welcome to have units control at the level of the element (dimension, label) or schedule. An electrician might prefer that fixture elevation in fractional inches, for instance. This will become more important as more annotations become automatic.

PS, metric people: Sure sure, I'm with you but you're not helping.

Element Transfer Settings is a new feature of Archicad 21. It allows the user much greater control over what settings are injected during a syringe operation and/or when favorites are applied. I haven't explored the feature enough yet to be inspired by what it can do, but I think it's going to be helpful.

But I have a problem with the way the feature behaves in projects migrated from Archicad 20. When you open a project in Archicad 21 the first time, a single ETS option is created, Transfer All Settings. As you would guess, every setting in every tool is checked off. This includes settings that didn't transfer in Archicad 20, such as story, ID, and zone name and number. These are the personally annoying results that drew my attention:

• Favorites are set to include the story. So on every story except the home story when the favorite was created, you will get that wonderful dialog box about changes on an unseen story, and then you undo, fix the story, and do it over. (In 20 this just behaved badly and acted like a bug. It works perfectly now once you know what ETS is.)

• ID is included, so if you use unique IDs to schedule elements such as doors and windows, you are going to start to see duplicate IDs (i.e., data loss) from using favorites or the syringe.

• I don't think I've ever eyedropper/syringed a zone, but if I did, I wouldn't want the name and number to transfer, that's crazy.

The old way in Archicad 20 offered some control over these things, so if you wanted to transfer ID via favorite you could, though you couldn't via syringe. (That's really confusing and the new way is better, once you know about it.)

So a migrating user of Archicad 21 is probably going to encounter frustration and data loss, before they even meet the new feature that is responsible. The migration process should have created a safer default ETS option. Note, this is only an issue with migration - the templates have a sensible assortment of options.

I have only made a few ETS options so far, but my default one excludes story, ID, name, number, reference ID, title, and label text content. I have a separate option to transfer label content. And I renamed the bad one to: 'Transfer All Settings BE CAREFUL'.

We use labels to show the ID of doors and windows in elevations. The labels are identical to the marker tags used in plan, and the pointer is left off.

With the pointer off, it makes no difference whether you use the single-click or three-click geometry method.

geometry method
Doesn't help

The label will be placed at a (non-user-modifiable) distance from the user-clicked point. (The text appears the same place if you use the single-click method with the pointer on.) Since that clicked point must be on the door/window in order to place the associative label, the label itself will usually show up off to the side of the opening. Then you have to move it into place on the opening.

offset label

(The way it should work: With the single click method and the pointer off, the label should be placed where the user clicked. This is one of those design issues that is so obvious I just call it a bug, opinions vary.)

Here is my best compromise method. Turn the pointer on. Use the three-click geometry method. Put the first click anywhere on the opening. Put the second click level with the point where you want the label. (After this click the Y coordinate is set.) Put the third click precisely where you want the label.

pointer label
Wrong, but be patient

Label all the openings in the elevation. Use find and select to select all the labels by name.

find and select
These ones

Turn the pointers off. The labels are off-center with the pointers on, but they will center on the third point with the pointers off.

good label

Much faster than adjusting each one.