On Land

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.

The Working Units and Levels preferences offer two reference levels in addition to project zero. It is common to set one of these levels to sea level. (We don't use the other one for anything at this time.)

With sea level set correctly, you can build your site model mesh using sea level topo data. Level dimension texts have autotext elements that can refer to sea level. Our standard story level markers and elevation marker objects can refer to sea level or project zero.

Reference levels are set in the Working Units and Levels preferences dialog.

Leave the 'relative to' marker on project zero. The sea level value is the elevation of project zero in the real world, which is usually the finish floor of the main story of the building. This value needs to be entered as a negative number, because it is below project zero. If you change the actual elevation of the project, you need to recalculate the sea level value and change it.

Sea level and the second reference level are only for display and input assistance. Elements are always placed relative to their stories and project zero. If you change sea level, you don't have to worry about your site mesh moving around, even if you used sea level values to set it up.

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

More»

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.

More»

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.

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:

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

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.

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.

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

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.

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.

More»

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.

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.

More»

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.

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

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.

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

Section and Elevation IDs are created by the user, and they need not be unique. 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.

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

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.

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.

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.

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.

The Drawing Manager appeared in Archicad 10, taking the place of Drawing Usage in PlotMaker 9. You can open it by clicking the button at the upper left of the Navigator.

It lists every drawing placed in the project, displays various settings of the drawings, and offers tools for performing drawing-related tasks such as updating, changing the linked view, breaking links, and changing drawing element settings.

You can perform most of these tasks elsewhere on a drawing-by-drawing basis by right-clicking on a drawing element, or on a drawing item in the layout book tree. But Drawing Manager offers you a power-editing mode where you can modify many drawings at once. Examples:

• Update all the manual-update drawings.

• Change all the instances of a drawing title to a different object.

• Make all of one kind of plan use a new, specialized pen set.

The key to these mass-modifications is to organize the list by the various properties, by clicking on the column headings. There is similar functionality in the Finder and many other programs.

For example, to update all the Manual Update items, click on the Update Type column, highlight the Manual ones, then click the update button.

For another example, sort by Drawing Title to change all the Drawing Title JM10 to Drawing Title JAM10a.

Etc.

In Archicad 11 they didn't change the Drawing Manager much, but they did change the way you choose what columns to display. In honor of the occasion I thought I should point out which columns are most valuable and which you should leave off.

If you right-click on any column header, you'll get this popup, where you can check the columns you want to see, and uncheck the ones you don't.

Columns can be resized by clicking and dragging on the joint between two headings.

If you look closely at the headings you'll see that one has a triangle and another has two triangles. The one is the last column you clicked, and the two is the previous click. This gives a two-level organization where the list is sorted by the last criteria, and within that, by the previous one.

These columns should be on:

• Type. Plan, section, external file, etc.
• ID. Of the drawing in its layout. Not critical, but it's little.
• Name. Of the drawing, which will usually be the name of the view that created it.
• Placed To. Name of the layout where the drawing is. (Usually a layout. Drawings can be placed in model windows, as you might a DWG. In this case that window would be listed here.)
• Source View. Name of the view from the view map, actually the whole path, including the stupid '/Residence' or '/Addition' notation. This is the kind of half-baked design decision you make when you develop primarily on Windows.
• Path. If it's an external drawing. Otherwise it says 'Internal'.
• Pen Set Name. Pen set assigned to drawing element. All drawings need a pen set.
• Update Type. Automatic or manual.
• Drawing Title. Object name of the automatic marker, if it's in use. Plans, among others, don't use automatic titles, so this field would be blank.

What? I know how to open a file! Jeez!

OK. Just in case:

Always open AC files via right click -> Open With or by dragging the file to requisite AC icon on the dock. I do the dock thing; I'm just not a context menu person usually.

Most important, don't double-click PLNs. Double-clicking will only give consistent, predictable results if you have exactly one copy of AC on your machine.

When you install a new version of AC, as you soon will in the form of 11, that version becomes the default application for opening PLNs. So you double-click your AC10 project, it opens in 11, you don't notice the difference because there isn't much, you save it, and next time you try to open it in 10 it doesn't work. (Yes, backsave. Real convenient.)

Always keep current versions of AC on the dock. Even if you use the right-click method, the dock gives you visual confirmation that the right application is being used.

Graphisoft gives poor support in this area, by making the icons identical and naming each version, precisely, "Archicad".

Double-clicking files is one of those 'automatic' things that's great if you can trust it, but when it's not predictable it makes trouble. It's not just AC either, recently my .docs started opening in Pages for some reason.

What about that 'Change All' under Open With in the Get Info window? That fixed my .doc issue, but it doesn't reliably assign the right 'Archicad' version.

So, right-click or dock. If you have a bad habit here, change it now before 11 starts getting on your nerves.

Update re app icons: Mr. Briggs to the rescue.

Summary: With the model and the layouts in one file, pen sets manage the difference between the model pens and the output pens. In addition, they can do view-option-type tricks.

Background: In Archicad 9, there was one set of pens. In PlotMaker 9, there was also only one, and it could be different from the set in AC. Or, each drawing could have its own pens, but it was impractical.

Our standard has always been to use a colorful set of pens for modeling, which translates into a black/white/gray set of pens in layouts. We are far from unique in this arrangement.

In 10, they threw PM into the abyss, so they needed a method to maintain at least those two groups of pens within the new unified project file. So, Pen Sets.

More»