Roundup of issues with daily shutdown, data backup, and power failures.
In Archicad terminology, a marker is a special object that has a subordinate relationship to another element, representing the element and/or saying something about it. Viewpoint markers represent viewpoints in project windows. Each viewpoint type has its own marker objects. There are default markers for each one in the Archicad library, but we (as usual) use customized stuff. Each marker is dedicated to a viewpoint, but all the markers have a lot of parameters in common. Here I will lay out those similarities, as well as the special features of each marker, while making sure we're clear on the correct marker for each viewpoint type.
Executive summary: A new layer for elements in layouts and in the title block worksheets. There should be no elements on the Archicad layer.
• The title block object and other stuff in its detail/worksheet window
• Drawing elements on layouts starting in AC10
• Master layout drawings and annotation elements
And it's never given us any trouble, but.
The concrete reason to forswear use of the Archicad layer is that it interferes with Teamwork. The only way to have the Archicad layer in your workspace is to have 'exclusive access' to the project, which is inconvenient in a real shared workflow. It's true that we don't use Teamwork much, but you never know.
Rather than confront the question under deadline pressure some time in the future, I'm changing the standards and templates now to include a layer for 'Layout' elements. This layer, +Z Layout, holds any element placed directly on a layout, including drawing elements, texts, PDFs, etc. It is also the layer for the title block object and anything else within the title block worksheets. The layer is visible and unlocked in all layer combinations except 0 Working Model.
Once all that always-showing stuff is placed on a regular layer that could potentially be hidden, you might wonder how to make sure it always shows anyway. The layout environment actually has its own layer settings, which are maintained simultaneously with the model window layers. Changing the layer settings of one does not affect the other, thank goodness. The templates are set up with the +Z Layout visible in the layouts. As long as you leave it alone, it will always show. If you do hide it, probably by accident, and WOW you'll know right away when everything vanishes, turn it back on. Layout layers are unaffected by view changes. This should be a set-it-forget-it situation.
Some people use multiple layers to turn layout elements on and off, but I don't see the advantage of that for us at the moment. One concern would be that layout layers can't be saved, with views or otherwise, so the user must remember to manage the layers before publication. I would be inclined to handle such visibility control in the title block worksheets. Here is some AC-Talk discussion.
The other advantage of using this standard is that the Archicad layer rule is much simpler: Don't use it, full stop.
Template changes:
• New layer +Z Layout. Show in all combos except Working Model.
• All title block worksheet elements to the new layer. Use F&S for all elements on AC layer, then Edit Selection Set to change.
• Set layer environment layers to combo xxAll, which shows everything.
• All master layout elements to the new layer. On each master, use F&S and ESS as above.
• All drawing elements on regular layout to the new layer. In Drawing Manager, sort by Placed To, highlight all non-master drawings, change layer in settings.
• Change default layer of Drawing tool.
• Redefine Drawing tool favorites with the new layer.
• Save favorites.
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.
What Shows
• General. The site plan is generated from the First Floor story. The 3D grade mesh is not shown because its pen and linetype options are too limited.
• Property boundary with metes and bounds. For the boundary, use an empty fill. (Only a fill can report its area, and you'll need the property area for the project information.) If north is set correctly and the boundary is precisely drawn, you can use and object for the metes and bounds, Survey Dim RND9, located in Graphic Symbols. Layers: +C Site Line.E for the boundary, and +C Site Note for the text.
• North arrow object. North Arrow JAM9, located in Graphic Symbols. If north is set correctly, you can turn on the 'Use Project North' parameter. Layer: +C Site Note.
• Setbacks. Layer: +C Site Line.E Use lines, arcs, or polylines. Setbacks should be labeled 'BRL' (building restriction line). Special restrictions can be labeled more specifically; 'Conservation Easement', for example. Layers: +C Site Line.E for the lines, and +C Site Note for the text.
• Topographic survey contours. If available. Use splines. Don't use lines, polylines or arcs. If you have lots of little segments, the dashed lines will never look right. Typically, we will get contours at two-foot intervals. The sea-level elevation of each contour should be called out, unless the contours are very closely spaced. In these cases, labeling only the ten-foot contours is OK. Layers: +C Contour.E and .N for the splines, and +C Site Note for the text.
• Building footprint. Layer: +C Footprint.N The footprint is the outline of the building as it meets grade. You will probably use the basement plan to get it. With the Site Plan layer combination active, show the A Wall Ext and S Wall2 layers. Trace the wall outlines with a polyline. You can show the basement story as trace (FKA ghost), or draw the polyline on the basement story and cut/paste it to the first floor.
Show dimensions from the footprint to the property boundary at key locations. For an addition project, the addition portion of the footprint should be filled with a diagonal pattern.
• Trees. If available. Use the object Tree JM10, located in 02 Site / Trees. Don't show removed trees unless you need to. Layers: L Tree2 or L Tree A. Trees on the 'A' layer will also show in the architectural plan. If you have modeled trees, you can place them on these layers or use L Tree3 to hide them in plans.
• Top view of building. This can be a roof plan or a 3D top view. This is a separate drawing overlaid on the site plan drawing.
• Additional building-related 2D elements. Anything you can't get to cooperate with the top view drawing can be drawn separately. Layer: +C House Line.
• Driveway. The layer L Drive2 shows in the site plan layer combinations. If you find that showing this driveway conflicts with the site plan somehow, you can modify the layer combination to hide it, and then redraw it with lines, arcs, and polylines on the +C Site Line.N layer.
• Street. Layer: +C Site Line.E Use lines, arcs, or polylines.
• Notes. Label the major site and project elements. These are, at least, the existing house and addition, the driveway, pools, large terraces, septic fields. Layer: +C Site Note.
Line Types
• Boundary: Property Dot-dash
• Setbacks: BRL long dash
• 2' contour: Dense dashed
• 10' contour: Long Dashed
• Driveway and street: Solid
• Footprint: Dense Dashed
Fonts
The usual, but to review: Lucida Sans for notes. Tahoma for dimensions including boundary data. The street name looks nice with a serif font; use Times.
Now we have some standard details, in the form of module files, which you can drop into whatever projects might appreciate them. They are located at 3 Resources / AC / External References / Standard Details. These are distinct from the Assembly Type details, which specify the components of walls, roofs, slabs, etc.
I will define a standard detail as a building condition always done in a certain way, independent of superficial architectural characteristics. For example, a brick window header will always be flashed with the same technique, regardless of the size or color of brick, the joint finish, or the shape of the brickmould. Those architectural specifications would be noted in other details and/or in the specs. Further, standard details represent CYA-type technical matters that we want to be sure not to forget, so the easier to drop them in the better.
The first wave of these details concerns the heads, jambs, and sills of openings (doors and windows) in walls finished with wood siding, stone, and brick.
How to use them
Create an independent detail window. Give it a descriptive name such as 'Typ Brick Window Head'. I like to use the ID field to keep the standard details separate from the 'real' details, so I would use an ID like 'Standard01'.
You can either merge or hotlink the desired module into this new detail window. Merge is essentially a paste operation, and the drawing elements will simply appear in the window and act normally.
Hotlinking maintains a live connection to the module file. If the module ever changes, you would get a notice to update it upon opening the file. Elements of hotlinked modules cannot be edited; the whole thing will act like a big locked group. (Module elements' nodes are square donuts instead of round.)
Which way is right. I will say merge in this case. As a 'Standard' detail, it shouldn't change often, and having fewer external references simplifies taking the project off-network.
Create a view of the detail window and drop it on a detail layout. Rinse and repeat.
More info
Don't be distracted by the Standard Details.PLN file in that External References folder. The project file is the administrative resource for generating the module files. Here is a summary of my detail method as it relates to the assembly types. Here is the really sick module generation method, which has nothing to do with the end user. 'Sick' can mean 'gross' or 'cool'.
Please let me know immediately if you encounter a module with multiple stories. How will you know? Such a module will not merge into a detail (or any non-plan) window, and you will get a warning to that effect. If you try the sensible workaround of merging the module into the plan window and then moving it, you will eventually notice multiple empty stories added to your project.
Both of these outcomes are sick in the uncool way.
This problem started in AC11, when it became possible to save multi-story modules. (Previously, if you wanted a three-story module, you needed three one-story modules.) This feature has a crippling bug that was reported in early beta, yet remains unfixed. When you publish a module from a multi-story project, you have a choice of what stories to publish: All, Current, or a range. It doesn't work. When you attempt to publish a single-story module, you get a module with all the stories of the parent project, with the content of only one story, the one that was 'current'.
So, after cool-sick publishing the modules, I have to gross-sick open each one of them and delete the extra stories. Of course, some day I will tune up a detail and re-publish it and then forget to fix it, and you will be sad when you try to merge it, and then you will tell me.
I would like to take this opportunity to express my great displeasure with Graphisoft's current quality assurance standards. This is a major bug in a medium-size new feature. They have known about it for months. They have released four patches to the shipping version on top of a number of beta versions. This bug impairs the ability of serious firms to use Archicad at a high level. It wastes your time and mine. It adds to the apprehension about future releases and how long they, in turn, will take to stop messing up our workflows, if ever. Archicad 10 still has what I consider show-stopping bugs, but it will never be patched again.
It is infuriating today and worrisome for the future.
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.
The behavior of IDs varies among the viewpoint types, so here's a cheat sheet.
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.
Standard pens updated for AC11.
Changing the pens is a pain, and it's potentially disruptive. I try to avoid it. With this update, I'm trying to minimize disruption while building a system that can adapt in the future. It should hold us for a while.
Template View Map orientation session.
Remember that views are viewpoints (stories, sections, details, etc) plus user options such as scale, layers, model view options, and dimension standards. Views become drawings in layouts.
We need views for each kind of output we're going to produce. Additionally, we want views for the various modes of work we do in the model.
We do the same kinds of output over and over, and the same kinds of model work. When you're doing the same things all the time, the templates should support you by getting a lot of it started.
These are the top-level subsets of the template view map:
• Working: Views which use the 'Working' Layer combinations. Use these views for day to day work on the project.
• Schematics: Intended for output in the schematic design phase. These views default to 1/8" scale.
• CDs: Intended for output in the Construction Documents and Design Development phases. The plan, section, and elevation views default to 1/4" scale. All other output subsets are included; interiors, structural, RCP, etc.
• Schedules: Views of schedule viewpoints for windows, doors, finishes, etc.
• 3D Views: Perspective, axonometric, top views from the 3D window.
• Note & Title: Title blocks, drawing list, vicinity map, project information, other annotation-type drawings.
• Background Plans: Stripped-down plans for DWG export if anyone asks.
• Binder: Small-scale plans and elevations for the post project binder.
Within the Working, Schematics, and CDs subsets, there are cloned subsets relating to the various viewpoint types, including at least:
• Plans
• Sections and elevations
• Wall sections
• Details
• Reflected ceiling plans
• Interior elevations and enlarged plans
• Electrical plans
• Structure plans
The Schematics and CDs divisions are named after the sheet they are published on: A1 Plans, A2 Elevations, and so on. Note the symmetry with the Schematics and CDs subsets in the layout book.
The divisions within the Working subset correspond to these output divisions: Working Plan, Working Elevation, on like that. (Working Model gives the whole model with no annotations.)
The working subsets are for us, and the others are for the documents.
I hope this illuminates the view map structure in our templates.
This will go live when we move to Archicad 11. It doesn't have anything to do with 11 per se, but it's easier to make organizational changes at a version break.
On 3 Resources / AC, we have a new folder called External References. This will hold all the external drawing and annotation resources which are used in the templates. These are:
• The Abbreviations PDF on the cover sheet.
• The Drawing Symbols PLN. This generates the views that wind up as the symbol keys on the cover sheet.
• The General Notes PDF for the T2 or T3 sheet.
• Standard assembly detail modules, which are hotlinked into detail windows.
• Electrical Plan symbols.
• Probably other things.
This is all the standard stuff. If a project has external references particular to itself, those go in the project folder.
In the current system, if you can call it that, we have these resources in at least three places and it's a hassle if you need to relink something. In the 11 template it's clearer.
Belated documentation of slightly modified, long-established AC10 project folder setup.
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.