On Land

Environment Information
At Rill Architects we run ArchiCAD on Mac OS X. 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.
Archicad Archive

« Newer | All Entries | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Older »

Intersection priorities help the user control interactions between certain elements. Wall and beam elements have their own intersection priority; I'm calling that the element priority. Composite skins (and components of custom profiles) have their own intersection priorities. Those are skin priorities. Neither of these should be confused with the intersection group number property of layers, though that bears on intersections too!

Element priorities effect plan and 3D geometry. Skin priorities effect only plan. Managing skin priorities is the key to proper automatic joint cleanup between composite walls in plan. Here's a look at the essentials of skin priorities and our standard composite setup.


Update: This method works through Archicad 12, with the key Recent Files. In 13 through 15, it still works, but the key you need to modify is called "Recent Documents". In 16, the Recent Documents key disappeared. Unfortunately I haven't been able to find where the recent documents are stored in 16 and 17.

Also: Under Mavericks (OS X 10.9), the developer of Pref Setter comes up as unidentified, and the current version will not run without modifying security preferences. The old version (I have 1.2.2) will run and seems to work fine.

It may happen that you would like to manually hack Archicad's recent files list. Recent projects are shown in the Start Archicad dialog box when AC launches. Recent projects and library parts are shown at File -> Recent Documents. One good reason to prune this list is that you can get apparent-duplicate items if you open a files from different locations, such as a server v. a local folder. Another reason is if you change servers and you need to make sure the recent items have the right address.

These are OS X instructions. We use the free utility Pref Setter to edit plist files. On Windows, use whatever Windows users use.

The AC preference files are at [home]/Library/Preferences/. There are a number of AC prefs; the one we want is com.graphisoft.AC .plist. You can right-click on the file and choose Open With... Pref Setter, or open the file from Pref Setter's File Menu.

The Pref Setter window will present all the 'Keys' in the plist file. Scroll to Recent Files.

Recent Files

Projects are listed first: Plan File_1., Plan File_2.,... You can delete any of these items. You can also modify the path in the Value field, to point to a different server, for example. Following the projects themselves, there is a Plan FileType_ item for each project. If you are deleting project items, you can delete these items as well, or not. It doesn't matter. Following that is a Plan Number item. This value is set automatically; you can ignore it.

After all the project list information, there is a similar arrangement for recent library parts that have been created or opened for editing. In this context the word 'Symbol' means library part: Symbol File_1., Symbol File_2.,... You can delete or hack these exactly like the project items.

(There are also integer keys for the number of RecentPlans (projects) and RecentObjects (library parts) you would like to see in the list. These are set to 12 by default, perhaps you would like more or fewer.)

We had to do some of this recently when we moved our projects, libraries, modules, etc. to a new server with a different address. When AC launches, it will try to make sure the recent files are accessible. This may lead to a prompt to log in to the missing server. Or, if the password for the server is stored in the user's keychain, the old server volumes can mount without you noticing it. Next comes confusion about where you are actually working, which is never good. Tip: Delete the password to the old server in Keychain Access. That way, you will be notified when AC wants to go looking where it shouldn't and you need to hack your prefs.

(To be honest, even after carefully working through this, I have seen AC mysteriously seek out the old volumes. There's some glitchy behavior going on, but it seems to settle down over time. We do what we can.)

All 3D elements have a User ID, known simply as the 'ID'. It can be observed and edited in the Info Box (near the top in our setup) and in the Settings dialog under the Listing And Labeling division.

The only 2D element with an ID is the Fill.

I wish other 2D elements had IDs. Then I could 'name' topo contours after their elevations.

You can access the ID field of a selected element by typing 'I'.

If the default settings ID ends with a number, the number will increment (increase by one) as elements are placed. Unless you switch off this preference in Preferences -> Miscellaneous. N.B.: The numbers will only cycle through the available numeric places. I.e., ABC9 will be followed by ABC0, but ABC09 will be followed by ABC10.

The default IDs of the tools in your templates should consist of an identifier for the tool (E.g., 'Roof' or 'R') followed by at least two digits, maybe three. This gives the incrementing room to operate.

Other than the automatic increment, Archicad never changes IDs by itself, and there's no problem with elements having identical IDs. (This is different from viewpoints, where the name/ID combination must be unique.) When you drag-copy or multiply an element, the copies will have the same ID as the original. When you eyedropper (alt/opt+click) an element, the ID of the next element will match, but the next one will increment, assuming the switch is on.

The ID is picked up by the eyedropper, but an existing element's ID isn't changed by the syringe.

I keep that Auto-increase preference on, and the only time it bugs me is when I'm placing Shape Tag objects for revisions, and I have to make sure the triangles say 2, 2, 2 instead of 2, 3, 4. (Really, that's just an illustration, because that object has a setting to use a custom text instead of the ID, but using the ID is easier because you edit it directly by typing 'I', bla bla bla)

Letter IDs do not increment, which makes sense now that I think of it. (WALL, WALM, WALN,... that's no good.)

If an element has an error in it, the ID will often appear in the report window warning. This is helpful, because you can use Find and Select to find elements by their ID, then track down the problem from there.

When you're searching for errant elements in this way, you will probably find many of a given ID, because of the drag-copying and eyedroppering described above. To isolate the troublemakers further, you can manage element IDs using a schedule.

We schedule doors and windows by their IDs, and you can change IDs directly within the schedule.

The only element type we deliberately give a blank ID is doors and windows we want to leave out of the schedule. This includes empty openings and weird openings like trim panels.

Zones have the same ID field as other model elements, but we ignore it in favor of the Zone Number field.

The GDL global variable for user ID is GLOB_ID. Elements also have an internal unique ID which is unmodifiable and invisible except in GDL. That global is GLOB_INTGUID. (I promised you trivia.) I can't recall using that one, but you need GLOB_ID all the time for markers and labels.

Somebody asked:

I have finally gotten frustrated enough with the way line types are (dis)organized to focus some effort on it. Have you figured out any tricks to getting line types to show up in any logical sequence at all in your files? I can't believe that after all this time GS hasn't just made it alphabetical. How hard can that be...?

Linetypes are sorted by their internal ID. All attributes (pens, materials, fills, etc.) have an internal ID. This ID is never visible in the general Archicad interface, though it winds up being very important. In settings dialogs, object parameters, and within other attributes (E.g., a composite uses a fill), the ID is what matters, not the name. The only place you can view and (sort of) manipulate IDs in in the Attribute Manager.

The other attribute types sort alphabetically in their lists, but for some reason linetypes don't. There's no excuse for this from the user's perspective, but you've probably noticed it's not the only charming eccentricity of AC's interface.

If you want the linetypes list to sort in a predictable way, you will need to hack their IDs. This is both a pain in the chair and not entirely free of risk.

If you change the geometry and/or name of the linetype at ID #4, all placed instances of linetype #4 in the project will change. If library objects have linetype #4 in their default parameters, suddenly they will have new defaults in those linetype parameters. Elements only care about IDs. Modifying libraries to adapt to such a change is prohibitive. Where the Archicad library is concerned, it's practically impossible because it's bad form to modify it at all. And, if you modify your own library, you have to be wary of affecting past projects going back however far, should you ever reopen them.

I did try to sort my linetypes a few years back. I survived, because we don't actually use very many, and I did some investigation to see what linetypes the AC library cares about. There is compromise involved. Our primary dashed line is at ID #2, but the AC library expects a dashed line at ID #4. If I put something else at ID #4, AC objects will display that instead of a dashed line. If I delete ID #4, those objects will have a missing linetype, which renders as solid, same problem. Meanwhile I can't abandon ID #2 because my libraries are hooked to that. So I'm stuck with two dashed linetypes at the top of my list, nothing I can do.

One more thing: If you do whip your list into shape, it will still be two lists, with the symbolic types following the vector types. Like symbolic and vector fills, that sorting can't be hacked.

As for how hard it might be for GS to fix this sort of thing, well, empirically it looks impossible. Hope to proved wrong.

Autogroup: On
Hide locked layers: Yes
Pet Palette movement: Jump
Tracker: Off
Coordinate Box: On
XY Button: Up
RA Button: Down
Move the origin a lot: Yes
Do that thing where you rest the cursor on a point and enter distances followed by + or -: No
Magnet: On
Info Box: Vertical
Navigator Preview: Off
Quick Layers: Off (Toolbar buttons)
Surface highlight selection: On
Contour highlight selection: Off
Info Tag: On, 100 second delay

I guess Autogroup isn't really an interface thing.

Or, seen and not seen. Fills, white pens, and materials.


The user has requirements. The software has capabilities. Where the capabilities end and the requirements keep going is a limit. To get beyond the limit requires workarounds. Some limits are harder than others and all we can do is wish (beg) them removed.

Here's a rich example concerning structural posts (columns) in residential construction. These are things like 4x4s, multiple 2x_s, steel pipe columns, tube (TS) shapes, and the occasional W shape placed vertically. Hard limits in Archicad are in bold. Stuff I've figured out is the rest of it.


A reference marker is a special object that can intelligently refer to viewpoints within the project or drawings placed on layouts. They also create viewpoints, which is a strange kind of double duty. Then you can also create viewpoints without markers... it's not intuitive overall. For most cases, you can think of a viewpoint as an application window. Sections, elevations, interior elevations, details, and worksheets are all viewpoints. So are schedules and even stories, but they are not related to the marker discussion in the same way. Everything in here applies equally to sections, elevations, and details.

A source marker creates a viewpoint. It is the viewpoint, in a manner of speaking. If you delete a source marker, you delete the viewpoint. If you copy a source marker, a new, additional viewpoint is created.

A linked marker is more like an object, though still a special one. When you place a linked marker, no viewpoint is created; the marker points to something. Any number of linked markers can point to a particular viewpoint or drawing. They are just pointers, and they can be created or destroyed without affecting anything else.

Both source and linked markers can refer to drawings.

You can have a viewpoint with no marker. Such a viewpoint is independent. You will very often have independent details. At this time all of our worksheets are independent. You can even have independent sections and elevations, but I don't see any advantage to these. Interior elevations can't be independent.

Choosing Source or Linked

When you get ready to place a marker, whether to draw a new section or refer to an existing detail, you will see these choices in the info box:

Marker creation options

When you select a marker, the options look like this:

Marker selection options

You can turn a source marker into a linked marker and vice versa, but don't. It's complicated, potentially destructive, and I'm pretty sure it's silly. Treat your viewpoints as 'real' things, and use linked markers to point to drawings in any way you like.

With Marker reference to
Marker ref to viewpoint
In our usage, markers usually refer to drawings in layouts, though they can also refer to viewpoints. Before a drawing is placed, source markers should refer to their viewpoints. In our section, elevation, and detail markers, you can tell the marker is referring to the viewpoint because the ID and name of the viewpoint are shown in the tag. The text is written with pen 10 (red), so if you print them they will appear empty.

In practice, a linked marker should always refer to a drawing. It makes for a smoother workflow if you place the drawing in the layout before placing linked markers.

When you choose to refer to the drawing rather than the viewpoint, you have three choices.

Marker reference to

The selected drawing lets you choose the drawing manually from the layout tree.

The first placed drawing of the viewpoint means you don't have to choose the drawing. The marker will find the first drawing of that viewpoint in the set and refer to that. You can choose this option before the drawing is placed. If you go this route, make sure the first drawing is the only drawing, or you are sure the first one is the one you want. N.B.: In our layout tree, the schematics sub-book comes before the CDs, so this 'first' thing will always use a schematic elevation instead of the same elevation in the CDs.

• Similarly, the first drawing of the selected view lets you name a view in advance of placing any drawing. When the drawing is placed in due time, the marker will refer to it. This 'first' method is safer, because 'view' is more specific than 'viewpoint'. For example, the schematics and CDs use different views.

With a source marker, you can only choose a viewpoint, view, or drawing associated with the marker's viewpoint. A linked marker can point to anything.

No drawing placed
If a marker is set to refer to a drawing but no drawing is placed yet, the tag will read #DrgID / #LayID. If you see this in a marker, it means the drawing isn't placed. Remember, if you see red text, the marker is still referring to the viewpoint.

Warnings about deleting markers

When you have a source marker selected and you strike delete, you will get a warning to the effect that deleting a source marker will also delete that marker's viewpoint, unless you choose to keep it as independent. If you confirm that you want to delete the viewpoint along with the marker, you be warned again, to the effect that deleting sections (e.g.) is not undoable. This second warning is as old as the section tool itself, and you know what it means.

If you delete a viewpoint from the Project Map, you will only get the warning about undoability. When a viewpoint is deleted in this way, its source marker and any linked markers are automatically deleted.

When you delete a linked marker, you don't get a warning, because nothing important or non-undoable is happening.

Model View Options, formerly known as Display Options, can be organized into combinations, kind of like layers, and MVO combinations can be saved with views. Naturally, this is all set up in the templates. MVOs are completely separate from On-screen View Options, which are screen-only and do not affect output.

The MVO dialog has three divisions. Options for Construction Elements concerns the display of real things, including openings, columns, beams, and markers. Options for Fills and Zones concerns how different categories of fills are displayed; turning cover fills on and off, e.g. Options for GDL Objects has only one item at the moment, the beloved Story Viewpoint Type, also known as the ceiling switch.

The keyboard shortcut to open the dialog is Cmd+9. I think the MVO dialog is pretty good about previewing the effects of most of the controls.

Rather than describe each combination, or heaven forbid build a table, I'll describe the A1/A2/A3 combination, then how the others differ.


Isn't north up? Probably not. Since the orientation of the project is driven by the geometry of the plan, north can be any which way.

Project North
In the Sun dialog
The north direction for the project is set in the Sun dialog. You get there via the Sun button in the Camera settings box, or via the More Sun button in the 3D Window Settings dialog. MORE: Karl Ottenstein points out that you can also go directly to the Sun dialog by right-clicking on any 3D viewpoint (camera, axon, etc.) in the Project Map, or on any 3D view in the View Map.

Note: Though it's called 'Project' north, it's true north, in that it's the only north, and the north used by the sun settings. Archicad doesn't directly support a project north environment variable separate from true north.

There are at least four reasons to set project north correctly:

• Accurate sun shadows

• Automatic orientation of north arrow symbol objects.

• Automatic dimensioning of metes and bounds using the Survey Dim RND9 object.

• Correct naming of interior elevations with the Orientation autotext. (A real project north would be nice here.)

For the purposes of sun shadows and interior elevation names, you can eyeball the north direction by moving the pointer in the Sun dialog. A degree or two off isn't going to hurt.

For the metes and bounds to work, you need to set the direction exactly.


Every viewpoint has a name and an ID. The name is important and is often used for output. The ID is never used for output, but wherever possible we use the ID to help organize the project map and view map.

Info Box name/ID
For viewpoints with with a marker, the name and ID appear in the Info Box and settings dialog. This applies to section, elevations, details, and interior elevations. (And worksheets, in theory, though in our usage worksheets usually don't have markers.)

Properties in Navigator
For all viewpoints, the name and ID appear at the bottom of the Navigator under the Properties heading. Viewpoints with fixed IDs, such as stories, will have the ID field in gray.

The behavior of IDs varies among the viewpoint types, so here's a cheat sheet.

Story IDs
Stories have unique, fixed IDs based on the order of stories. They are ugly. We ignore them.

Section IDs
Section and Elevation IDs are created by the user, and they need not be unique, but the name/ID combination must be. (If you try to create a section/elevation with an identical name and ID, AC will automatically append a number to the ID.) Sections and elevations should have an ID roughly corresponding to their sheet number. Building elevations and sections get A2-1, A2-2, etc., and wall sections get A3-1, A3-2, etc. For sections, add a letter to indicate the direction the section is facing. Don't put the direction in the name. For 'Junk' sections, used for modeling support and not for output, the ID should be xn where n is a number. (Yes, junk sections should usually be sections, not elevations.) So you end up with a section list of output viewpoints at the top, followed by all the junk.

Interiors IDs
Interior Elevation IDs should start with A5. I like to use the ID to sort the interiors by story: Basement is A5-0, first floor is A5-1, etc. Like the sections and elevations, the actual output sheet may differ. The sorting is to help you know where to look in the view map.

Detail IDs
Detail IDs need not be unique. (In AC10 and earlier, they had to be.) Still, it's a good habit to make them distinctive. I find it helpful to use the detail ID to give the 'category' of detail. For example, a bunch of eave details will have IDs of Eave01, Eave02, etc. The assembly type details have Type01, Type02, etc. Structure detail IDs start with S_ followed by a number. For all details, the name should be presentable for the automatic drawing title.

Worksheet IDs
Worksheets are a new, mostly redundant viewpoint type in AC11. We could easily live without them, but since they exist, we park all the straggly non-detail drawing things there. There aren't enough worksheets in a typical project to worry about sorting the list, so I recommend leaving the ID blank and just using the name.

Schedules, too, aren't abundant enough to sort. Leave the ID blank.

Cameras and paths have unique IDs that can't be changed.

Summary: Viewpoint IDs are not used for output, so use them to help sort the lists. Names are used for output: Use the name you want to see on the paper.

The IDs that do matter for output are those of the layout book items; subsets, layouts, and drawings.

Drawing IDs are usually generated by the layout, either by the grid or the order of drawings in the layout book tree.

Layout IDs are usually generated by the subset.

Subset IDs are set by the user, and the subset ID becomes part of the layout ID.

Views also have IDs, but they should typically inherit the viewpoints' IDs, so the lists will appear the same to us. All view IDs can be customized or set to 'None', but you can usually just leave them be. In the templates, I have deleted all the IDs for story (plan) views, because stuff like "-1. Basement" looks idiotic.

Somebody asked why the flue object can't show a thickness for the flue liner itself.

Flue on Nothing
One reason: The flue sits atop, and lines up with, the top of the smoke chamber object. In section this gives a continuous void. If a thickness is built in to the flue, there would be a discontinuity at the top of the smoke chamber, and the flue would appear to be supported by nothing. Building the flue thickness should help make a better detail, yet this is worse. I could partly solve this by narrowing the top of the smoke chamber, but that doesn't help with the other, bigger, reason.

The other reason: The flue is designed with SEOs in mind. You have to use it as a subtraction operator, or there's no point. It is a simple solid tube (EXTRUDE, actually) which we use to make a simple void. If the flue wall has a thickness, it becomes a solid ring with nothing in the middle.

Flue Filled
When you subtract with a ring, you get a ring-shaped void, with solid, un-subtracted material in the middle. If you cut a section through such a thing, you'll get masonry fill with two stripes of flue-wall fill going through it, and no void.

Flue Air Fake Air
To fix that, I could simulate emptiness within the flue by filling it with solid stuff with a clear section fill. In order to see this stuff and the wall thickness, we would need to make the flue's layer solid instead of wireframe. The problem there is that in a marqueed 3D view, there would be no void.

Well, I could wireframe the layer in building section combinations and make it solid in wall section, and I could make the thickness option scale sensitive in the flue and the smoke chamber, but we're into serious inelegance now. It's a void, except when it's not and it's simulating a void, and it's scale- and layer combination-dependent, and do I 'really' subtract it to 'simulate' a void, I can't remember.

Once again we have met a limit in GDL object technology where the simplest solution is for Graphisoft to give us more power. There is a directive, MODEL, which allows you to build shapes in wireframe or surfaces-only mode in addition to the default, normal, solid mode. MODEL WIRE makes a wireframe shape that looks exactly like switching a layer to wireframe. MODEL SURFACE makes a shape that looks normal from the outside but is hollow. This sounds promising for our problem until we realize that only MODEL SOLID shapes can act as SEO operators.

Therefore, I want a new MODEL option which will make shapes wireframe, but which will allow the shapes to act as operators. So the flue wall would subtract, and the void within the flue would subtract, but the void would still be a void. My first stab at a name is MODEL OPERATOR, but I'm open to suggestions.

« Newer | All Entries | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Older »