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.
RSS

We reviewed some things that people were a little sketchy on.

Which libraries should you use

• The current version's Archicad Library, which is located in the Applications folder, at Graphisoft/Archicad [n]. When you migrate a project to a newer version, you might also pick up an Archicad [n-1] Migration Library.

• The current version's Rill Library, which is located on the Carrot at 2 Libraries/Master LIB [n].

• Do not load the Development library, located within the Master Library folders. Objects in there are in an unreliable state from your point of view. They may vanish or turn into something else without notice.

• Do not load the entire Master LIB folder. That would give the Development folder hazard above, as well as potential duplicates from the Archived Items folder.

• When you migrate a project to a new version, change to the matching version of our Rill library. I do not maintain library parts more than one version back for very long. You will soon be out of date.

• If you have missing or duplicate parts, fix them. You should never see the library loading report.

Here is more on library management and what libraries are where.

Projects need to be on the server

If you take a project file elsewhere to work on it, make sure you put the modified version on the server when you return. If you aren't here and someone else needs to access the project, we need to be confident that it is current.

Where is your drawing list

I have seen cover sheets with no drawing list, and the drawing list box is still titled, "Drawing List". This looks dumb and bad. Drawing lists are generally required by permit authorities, and it is bad user experience not to have them.

Linked detail markers

This is an old, very important, core feature of Archicad. Here is a very old post about it. Nothing has changed.

Here I will re-summarize the detail workflow:

• The default settings of the detail tool in the templates are: create new viewpoint (source marker), in reference to the viewpoint, with the layer +Z SE Hide. To draw details based on other viewpoints' content, use the marker Detail Area JM10.

• Place the new marker with the "Create new detail viewpoint" option. This becomes a source marker. Develop the detail content.

• Save a view of the detail in the CDs/A3 Details/ subset.

• Place the view as a drawing in a layout.

• Return to the detail marker and change the reference to the first placed drawing of the viewpoint. (This is generally robust because there is probably only one drawing instance of that detail.) Change the layer of the marker to +Z SE Print.

• If you need to call out the detail from other locations, drag or copy/paste the marker. The new copies will be linked markers in reference to the selected viewpoint, which is the original detail.

• You can use other detail marker objects to refer to details you have developed using the Detail Area. Those would be placed as linked markers to a selected drawing.

• You can move the detail drawing around the set as you like. If you have to move the drawing to a different sheet, drag it in the navigator rather than cut/pasting it. If you cut or delete the drawing, the markers will go bad.

• To call out any placed drawing, use a linked marker in reference to "the selected drawing".

Composite separators should be off for stud walls

For composites representing 2x4 and 2x6 stud walls, the lines showing the drywall and sheathing should be off. At 1/4" scale, they don't read individually and add extra wait to the main wall outline.

• In the composite settings, Use Skin Separator Line should be unchecked.

• In the wall settings, Use Structure's Separator Line should be on.

You Actually Do Have To Split Walls To Demolish Openings

I have much more to say about this.

Keep junk sections junky, and don't have too many

It is very useful to use non-output sections to work on the model. I call these junk sections. They use a simplified marker, a subtle pen color, no names, and IDs of the series x1, x2, ... They are set up in the templates and in the favorites.

Junk sections should never have names like output sections. This makes your Project Map and View Map very confusing. If you have junk sections with real names, fix them.

Never use junk sections for anything important. If you use a junk section to create a detail, or turn one into an output section, then change the pen, marker, and/or name to account for this.

Don't have too many. It is better to have a handful and move them around. Having many sections and elevations will eventually affect file performance. In order to move them around without worry, you need to be confident they are truly junk; see the rules above.

Don't use Up, Down, Left, Right in section or IE output names

Elevations of the exterior should be called Front, Rear, Left, and Right.

Interior elevations, by default, should be named after the room and the compass direction of the elevated wall. Both of these can be automated if you are using zones (for the name) and have Project North set correctly (for the direction).

Up, Down, Left, and Right refer to the plans, not to the building. It looks odd to see a title like "Kitchen Down"; what is that, the floor?

Interior elevation names can be customized if it makes the title clearer. If there is only one elevation of a room, you can just name it after the room. In the kitchen you can name it after the equipment on that side. At a kitchen island, you name them after the things they face, e.g., "Island Facing Sink". For most walls worth elevating, it is evident what is special about them, and beyond the room name the title doesn't add much. It just shouldn't be confusing.

I think the Up, Down, Left, Right idea comes from the IDs we use for building sections. (A2-4R Cross Section looks to the right, A2-4L looks to the left.) These are good, because the help make the name-ID combination unique. But they have nothing to do with output.

This is the 9-years-bugging-me thing from a couple days ago.

I have used doors and windows of my own making since Archicad 8. When I started, it seemed essential to getting our projects looking the way we want; the Archicad Library items just didn't do the job. I know they have improved over the years, but I don't know how much, because I don't use them. I'm sure they are better in many ways than mine, being more full-service, but that's the thing: Mine do exactly what I want, and they don't do other things. When I need a feature, rather than wishing for it, I add it. This is the still-underrated power of GDL.

I'm not saying you should develop your own doors and windows, you likely shouldn't. But having started, I continue. My libraries work well, and I don't pay much attention to changes in that part of the Archicad library. But in AC17, Graphisoft made quite a big change in the behavior of the opening tools themselves, which exposed what was previously an inconsequential limitation in my doors and windows.

One of the things I decided very early on to ignore is the "Flip" button in door and window settings. If you're using my library parts, you don't use this switch. You rotate and/or mirror the element. In our practice, which is US residential mostly wood framing, the flip switch doesn't offer any advantage.

Bad flip
So, my doors and windows aren't designed to work with the flip switch, and if you "Flip" them, you will immediately see that you should "Flip" them back. Installing doors so they are entirely outside the wall is not sound practice!

I always sort of wondered why this was, but it was never a priority because I don't use the feature and don't feel compelled to start.

Bad door placement

But in AC17, the new UI of placing openings essentially allows you to place the opening flipped, which leads to a confusing user experience if the library parts don't support flipping. So I finally took the few minutes required to get to the bottom of it. (Search for "flip" in GDL manual, Google "WIDO_FRAME_THICKNESS", read this Archicadwiki article, at least that part of it.)

Simply put, when the flip switch is activated, the door or window is mirrored across the "reveal side" face, and shifted by the "nominal frame width", which is a special value in the compatibility options of the details tab. This value can be a length or a GDL expression that uses parameters. It is zero by default, so the shift that should follow the mirroring doesn't take place. I don't use the built in "reveals" (they are also on the ignored feature list), so for my doors and windows this value is just the wall thickness (global variable WALL_THICKNESS, though I still prefer the old name C_).

Nominal frame thickness

I'm still not flipping my doors and windows, but now they don't look ridiculous when placing them in AC17.

There is one case where this info might matter to users that doesn't have their own libraries: When saving a custom, slabified opening from the 3D window. When you place that part in AC17, you will get the confusing flipping behavior unless you set the nominal frame thickness to WALL_THICKNESS, or to the dimension of an actual frame component, if appropriate. It just shouldn't be zero. It would be nice if the saving process for those parts did this automatically.

I also don't like that they use a sun icon to represent the reveal side as if the reveal side were always outside, but that is another topic.


Library Globals were introduced in Archicad 13. But I only noticed them after jumping to 16, and by that time there were enough examples in the wild to make their value clear. They have enormous potential, especially compared to their relative ease of use, if you are already a GDL/library/standards person.

In GDL there are Global variables, which make information about the project available to library parts. Some globals contain environment information like the current scale, the north direction, or the current viewpoint (window) type. Others are element-specific, so doors and windows can behave intelligently within their walls, for example. Labels can use globals to automatically display information about elements.

Globals are just there, waiting for you to mention them. The global for the current scale is GLOB_SCALE, so:

IF GLOB_SCALE <=48 THEN
     [fancymodel]
ELSE
     [simplemodel]
ENDIF

...means at 1/4" scale or larger, make the fancy version, and at smaller scales make the simple one.

In addition there are Requests, which are different in syntax but have a very similar function. A request I use often is "Height_of_style", which tells you how tall a block of text is. Unlike globals, before you can use the information you have to move it into your own variable.

rr=REQUEST("Height_of_style", textStyle, styleHeight)

The parts of that line are, in order:

rr is a variable to hold the return value of the request, which is not the data we are requesting. Instead it reports if the request was "successful". You can leave it out and the request will still work, but you will get an error. "rr" is my personal preference; it can be "n" or "success" or whatever.

REQUEST("Height_of_style" is the name of the request.

"textStyle" is my previously defined style in the script. You need at least one style defined to do anything with text.

"styleHeight" is my variable to hold the data about the height, which is what we are looking for. Now I can do stuff with that value, like draw a line as long as a text element is tall:

LINE2 0, 0, 0, styleHeight

Other requests can look up the current dimension preferences, the state of model view options, etc., etc. There's a complete list in the GDL manual.

I'm hazy on what makes a bit of information a global or a request. (Why is the layer a global, but the zone category a request?) Anyway, both kinds of things are defined internally by the program, and that was all there was, until Library Globals.

Library Globals allow library developers to create their own model view options.

Let's say I want the steel column objects to display differently in the framing plans and the architectural plans. In vanilla Archicad, that's not a model view option. With doors and windows, I can control whether the openings, symbols, and markers are shown, and then save those settings with the views for different plan types. Not so with the steel columns. I could have a setting in the object to change the appearance, but it's the user's job to switch it back and forth. (Tip: Any workflow with the phrase "user's job to switch it back and forth" is not an optimized workflow.)

With Library Globals, I can create a setting in model view options to change the appearance. I can have the objects respond to the setting automatically. And finally, I can save the setting with the view.

I can create a setting. I can make the objects respond to it. I can save the setting with the view. Are you getting it? I am excited about the potential of this feature.

There are two parts to it:

1. The Library Globals Settings object. This is a hidden object with the "Library Globals Settings" subtype. Parameters in this object become settings the user can modify in model view options. The interface script of this object provides the interface for those settings within the MVO dialog box.

2. The LIBRARYGLOBAL keyword. This works very much like REQUEST, above.

Here is my first application for this feature. I would like to show some structural columns on the story below, dashed, so that in the structure plans you can see that the point loads are being picked up. While I don't mind seeing structural columns in the architectural plans, the dashed-below thing really doesn't work. You get dashed columns in the middle of rooms, which is confusing. So if I want structural columns in the architectural plans I can't show them dashed below in structure plans. And if I want dashed-below columns in structure, I have to turn the columns off in architectural.

What I need is a separate control for display of the dashed-below columns. Library Globals finally provide this.

Again, there are two parts. You need an object with the "Library Globals Settings" subtype. Ours is called "RillLibraryGlobals". You only need one object, even if you are planning settings which affect many different objects. Within the object, I have a parameter with the name "LG_ShowColBelow" (The LG_ prefix reminds me that it's a library global parameter, which clarifies the script on the other end.)

In this simple case, the only script you need in the library globals object is the interface script. This script creates the interface within the Model View Options dialog, where the user will manipulate the setting. Interface script technique is beyond the scope of this post, but the briefest thing that will non-beautifully work looks something like this:

UI_DIALOG 'Options For Rill Libraries', 600, 300
UI_PAGE 1
UI_STYLE 0, 0 ! Small, Normal
     UI_OUTFIELD 'Show posts on story below', 12, 22+5, 148, 22
          UI_INFIELD 'LG_ShowColBelow', 160, 2, 48, 22

Which ends up looking like this in the MVO dialog:

Show columns

That checkbox flips the setting behind the scenes.

The second part is in the object itself, in this case my steel column. The 2D script of the object needs to know about that setting in the library globals object. It's very similar to REQUEST:

!! Library global for column below, show in S, hide in A1
LG_ShowColBelow_val=0 !!initializing
rr=LIBRARYGLOBAL ('RillLibraryGlobals', 'LG_ShowColBelow', LG_ShowColBelow_val)
IF GLOB_CH_STORY_DIST=-1 & LG_ShowColBelow_val=0 THEN END

'RillLibraryGlobals' is the name of the library globals object. 'LG_ShowColBelow' is the name of the library globals parameter being asked about. LG_ShowColBelow_val is a local variable, just initialized, to hold the value found in the library global variable.

The last line says, if we're on the story below the object's home story, and that library global checkbox is off, don't draw anything (END). GLOB_CH_STORY_DIST is the ordinary global variable which says which story we are on relative to the object's home story. One story down is -1.

Then later in the script when it's time to actually draw the column:

IF GLOB_CH_STORY_DIST=-1 & LG_ShowColBelow_val=1 THEN !! story below
     [Draw dashed symbol]
ELSE !! home story
     [Draw solid symbol]
ENDIF

Of course, it's still up to the user to set the object itself to display on the story below. With that set, the MVO checkbox will control the actual display.

Finally, in the Model View Option combinations, that checkbox is on in the structure plans, and off everywhere else.

If we had this model view option, it would greatly help the scale-sensitivity problem for composites and profiles. Background only for small scale output, detailed fills at large scales.

I've wanted scale-sensitive composites as long as I can remember. This seems easier? Note the cover fill option right there. Drafting fills too, sure. Consistency.

Solid Background On Cut Fills Please
Carrot
All the server libraries are in a volume called "2 Libraries", whose icon is a carrot which predates OS X and looks it, and we call the libraries volume the carrot. This is what's there:

BIM Server Libraries. Copies of our standard libraries for use in Teamwork projects.

Library Container Files. An LCF is a compressed archive of a library. It loads very fast and can't be messed up, so it's good for taking projects on the road assuming you don't need to modify standard parts. I try to update the LCF of our current versions' library (13 and 16 at the moment) on a weekly basis. But I might forget, and I certainly modify objects throughout the week, so if you need the LCF you should make sure it's up to date.

Master LIB [n]. Where n is between 7 and 17. The Master folder contains the current "1 Rill LIB[n]" folder, which is standard library that must be loaded for all current projects. It also contains a "Development" folder, which should generally not be loaded; things in there are either broken, unfinished, or otherwise unworthy.

When we start using a new version of Archicad, I copy the entire Master LIB folder and give it the new number. When you switch a project to a new version, you should also change to the newer Master LIB. It will be virtually identical to begin with, but over time the old versions will fall behind. I generally only treat the newest Master LIB as "live" for the purposes of new development and bug-fixing. Back-saving objects, unlike PLN files, is nearly prohibitive in its awkwardness.

Other LIBs. Just what it says. Old project libraries from the pre-embedded days. Old Archicad libraries. (I've lost the 5.1, but we still have the 6.0.) Extracted versions of recent/current Archicad libraries. (Archicad libraries are LCF files. If you want to search them using the Finder, they need to be extracted.)

This is everything I can think of about libraries management. There have been a lot of changes over the years.

More»

Alphabetical by name of thing. Please suggest improvements and additions. Many things have changed, many have stayed the same. Layer theory hasn't changed much. Current as of 16, and I'm not anticipating big differences in 17.

Big table below the fold.

More»


Typically we try to get the existing conditions completed before starting demolition and new construction. It's good practice to save a copy of the PLN at this stage, along with a PDF of the existing plans. But in principle, we should be able to get existing plans out of the project at any stage, and there might be projects where it's not practical to absolutely finish the existing conditions before the design work starts. And this almost works, with some workarounds.

Let's review the basic attribute and renovation filter setup. The natural background color of walls is gray. New walls are gray in output, so the filters are set for new to show; they are never overridden. Existing walls are white in output, so the filters are set for existing to be overridden. Demo elements are white and dashed in output, so they are overridden as well.

In the template, the Existing Conditions filter is set to override the existing elements, turning them white. The demolished elements are set to be shown, but if no elements have been demolished yet that doesn't matter. New elements are hidden, but they don't exist yet. So to publish existing plans at this stage is very simple, because there are no other statuses to account for. Nothing is gray or dashed.

Existing Conditions
Existing conditions before design work

Once the design work has started, if you want existing plans you need to show the demolished elements. And the filters certainly offer this capability.

Remember that the natural fill color of elements is gray. Existing elements are overridden to turn them white. We'd like to keep that. But we can't override the demolished elements, because we don't want dashed lines.

Dashed demo
Existing and demo are overridden, like in demo plans

Instead they are shown, which means the demo walls will be gray.

Gray demo
Existing is overridden, demo is shown

In order to keep the lines solid and turn the fills white, we need to apply a pen set to the drawing element. The poche pen is number 50; all the pen set does is make it white instead of gray. (Yes the screenshot is still of the floor plan. I want them to all look alike. Pen set hacks for output should only be applied to the drawing element, never to to the view.)

Dashed why
Existing is overridden, demo is shown, pen set turns the walls white

But this doesn't quite solve it. With existing elements overridden and demolished elements showing, you will get a dashed line wherever a new opening is placed in an existing wall. I would call this a bug, because if the demolished elements are showing, you should never see the dashed line because it's part of the override style.

If you set both the existing and demolition to show, then the ("new") openings vanish.

All good
Existing and demo are shown, pen set turns the walls white

The existing plans have the pen set ("Layout Existing Plan") applied to them in the template, though if you publish existing plans before demolition, the pen set isn't needed because the existing elements are overridden to white anyway. The pen set is applied this way just in case.

If you need to publish existing plans after demolition has started, you have to change the Existing Conditions filter so the existing elements are shown instead of overridden. Then both the existing and demo elements are the natural gray color, but both are turned white by the pen set in the drawing.

This is a royal pain! It's hard to figure out, hard to explain, and almost impossible to remember. We have to jump through these hoops because of an incomplete feature compounded by a bug. The incompleteness is the inability to vary the override style by filter. We need to override the demolished elements differently for existing and demolition plans. The bug is the display of demolished elements with overridden attributes even though the filter is set to show.

We are on our third version of Archicad with the Renovation feature. This stuff should be solved by now.

These guidelines are current as of Archicad 16 and 17.

More»

Somebody asked about the animated gifs in the Renovation post and elsewhere. (My favorite one is of the roof with the FPCP.)

An animated gif is special image format which allows multiple frames, with each frame shown for a certain length of time, in a loop. Animated gifs based on video have lots of frames, with very short delays simulating motion picture frames-per-second rates.

My screenshot gifs have a handful of frames with long delays. They are very simple to make. Without the specifics of any particular application, the steps are:

Take a series of screenshots of the same size, one for each step of your process. The application needs, at the very least, to be able to remember the last selection you used. (The built-in Cmd+Shift+4 function on the Mac does not do this.) Save each image in gif format, or convert them using virtually any image processing application. (But not Preview in OS X, why why why.)

In the gif-creating application, drop the images in, in order. Set the delay for each frame. One to two seconds is a good place to start. Save the whole thing, drag it to the web browser, and enjoy.

For screen capture, I have used Snapz Pro X for years, but it hasn't kept up with progress and started losing its mind under Mavericks. I recently dismissed it in favor of Voilà. (The selection-remembering setting is in Preferences.)

For image editing, I've been using Acorn and Pixelmator, but Voilà seems to provide a lot of editing and annotation features on its own so outside editing of the frames might not be necessary.

For the gifs themselves, I'm currently using GIF Animator which I found in the Mac app store and might have cost $1. This is basically the whole interface:

Gif Animator

Photoshop can do it, for more than $1.

PS, Hard G.