ArchiCAD Layer Theory Part 5
Before we get to the official naming conventions article I’ve been teasing, I need to return to Layers. My post Pen Sets, Part Eight: Thoughts on Naming and a coincidental encounter made me realize that I was doing Layer names wrong, at least for how I use Layers. Below are the links to the first four posts on Layers (don’t forget to read the comments). These posts will catch you up on how I and others view Layers. You don’t need to read them all to understand this one, but together they are building an overarching concept of how to view Layers.
- Part 1: LEGO and Layers
- Part 2: Do you need that Layer?
- Part 3: Layer Combinations
- Part 4: Different Kinds of Models
A Fortunate Presentation
We had a user group at the end of February. Geoff Briggs presented. I know Geoff well. We’ve communicated for years online. We’ve both been beta testers. We first officially met in person at the first Graphisoft North America BIM Conference in San Diego back in 2013. Now that we both live in Seattle, we meet monthly to talk about ArchiCAD and drink beer. Some months its continuing the user group at a nearby bar. Other months it’s just a bunch of ArchiCAD nerds getting together on a Friday night. I think we even live close enough that I could walk to his house. Needless to say, I’ve heard and read Geoff’s thoughts on ArchiCAD, a lot.
At our most recent ArchiCAD user group, Geoff graciously volunteered to present. As with any ArchiCAD guru, his conversation kept returning to his thoughts on templates and project set up. I love hearing Geoff talk because he knows a ton about ArchiCAD, and has been using ArchiCAD for years and years. He’s one of three highly regarded gurus in the Seattle area (the others being myself and Thomas Bormann). But I also REALLY like hearing Geoff talk and show off all the wild and wonderful things he can make ArchiCAD do because we disagree about almost everything. Or I should say we have extremely opposing views about how to get to a similar end result. He models footings with slabs; I do it with beams. He models certain changes in wall materiality with a zero depth niche; I do it with beams. He breaks a wall into multiple elements to make it stepped; I do it with beams. Jeez. I use beams for a lot of things! That’s not the point. Geoff and I both have great solutions for all sorts of things in ArchiCAD, and we’re both correct in our logic. This is one of the things I really love about ArchiCAD. There are many, many, many great ways to model, embed data, etc. There’s rarely one ultimate solution. Everything involves trade-offs, even if it’s something minor like the number of clicks or the ease of explaining a workflow to coworkers; or something bigger like how a technique affects model size or the ability to export the geometry properly to IFC.
Every time I get to hear Geoff talk about ArchiCAD, it’s a treat. His logic is so different from my own that it really helps me see ArchiCAD in new ways. The result is that it sometimes leads me to random ideas (like putting big red spheres in the middle of rooms that you don’t want your clients to look at in a BIMx model—which I think would work better than my other tricks—but I’ll talk about that more later). Other times I listen to him and think, ‘No Geoff. You are crazy. You’re just helping me understand why my ideas are so much better than yours. In fact, your solution has shown me all these other reasons why my answers are so fantastically great and wonderful.’ And sometimes Geoff shows me how I need to steal his ideas and start using them, because my ideas are garbage compared to his. I know Geoff’s responses to my opinions run the same gambit.
The Tyranny of Alphabetical Order
The big revelation Geoff shared during our ArchiCAD user group in Seattle was that he misuses Layer names to add a more complex and functional ordering system for Layers. This solution is so much better than simple alphabetical order. I’d already implemented a similar system for Pen Sets (see Part 8), Layer Combinations, and Renovation Filters, but for some reason I was too timid to apply this logic to Layers themselves.
I want to point out that this isn’t the first time I’ve come across this layering concept. Eduardo Rolón showed me a similar solution many years ago (but I wasn’t ready for it). And Geoff also said he got the idea from another user he knows. Which is why I think it’s so important to share these ideas. None of these ideas our any one individual’s; they are collectively OUR ideas.
So what’s Geoff’s Layer naming methodology? First he adds a number before each Layer, so that instead of being locked into the random first letter of the Layer, he can group them in a more logical order. Being able to group Layers in a manner that isn’t limited by the arbitrary tyranny of alphabetical order is liberating. With this system all your annotation Layers can be together, all your MEP Layers can be together, all your utility Layers are grouped, etc. And second, Geoff adds dummy layers that are used to separate the groups and act as a title for each section. Geoff’s exact groupings are a bit different than mine (because of course we disagree about what Layers a file needs) and I’ve made some other minor tweaks, but the overarching concept is the same. Here’s my new Layer list:
This reworking of Layer names is fantastic.
- The titles of each group are dummy Layers. There should NEVER be any elements on these Layers. Ever. They are for organization only. They are always locked and turned off. This means when you are scrolling through Layers in the Info Box, these title Layers are grayed out and jumped over. This reinforces the grouping of Layers and makes it so easy to see the Layers as part of distinct groups rather than random items in a list.
- The “|” after the group number makes reading the Layer name much easier, especially in the Info Box, where the Layer Intersection Group already shows up with a vertical line after the number. As an example, in the Info Box you’ll see 1 | 5 | Footing.Structural for a Layer with Intersection Group 1, the name “5 | Footing” and the extension “Structural”. Not having the “|” in the dummy title Layers, also helps those stand out even more.
- As was already discussed, the ability to group Layers more naturally, rather than just by alphabetical order is amazing. No longer are Wall Layers relegated to the bottom of an ever expanding list. They can be at the top, right where I want them.
- I use Layer Extensions, though I know many people don’t. I find that, within this system, Layer Extensions adds another level of hierarchy, which I really like.
- Layers that don’t follow this numbered ordering system will automatically be filtered and appear below the 9 ●●●●● Trash Layers ●●●●● 9 Layer. Some random Layer that doesn’t belong (because it was copied in, created by a lazy coworker, merged from a DWG, etc.) will alphabetically show up below that title Layer—assuming it doesn’t start with a number. But even if it does, the odds of it starting with “Number” then “|” are pretty small. So non-standard Layers should be obvious.
- This layering system also helps teach users what to focus on. For instance, if you are starting a new model, you should focus on the “1” Layers first, then the “2” Layers, then the “3” Layers, etc. This isn’t perfectly true, as I might do foundations before stairs, or some site work before trim. But in general this segmentation is a good starting point.
- Not only do the Layers organize by where to start working, they are also set up hierarchically by what you need most often: when working in ArchiCAD, you need the primary and secondary modeling Layers more than you need mechanical and electrical Layers or misc. Layers. The Layers you need more often are higher on the list, and therefore more often visible. You might think you need Documentation regularly, but most of the elements on those Layers should be started from Favorites, so the actual frequency of needing to change documentation element Layers should be fairly minimal.
- If you need to add Layers to your template or project, it should be obvious both what kind of Layers you need and where they should go based on the numbering system. Is it a model Layer or a documentation Layer or a consultant Layer? If the Layer you think you need doesn’t fit into any of the categories, maybe it doesn’t belong in your file. This partitioning of Layers helps you understand why you are using the layers you have. Remember from Part 4: Diffrent Types of Models, your layering system might be about energy or cost or something else. In that case your groupings wouldn’t be Model, Primary; Model, Secondary; etc… They might be $50 sq. ft.; $100 sq. ft.; Documentation; Owner Supplied; Free…
Naming brings order out of Chaos
Without a doubt it’d be great if we could do this layering system in ArchiCAD without a work around. I’d love to have Layer Folders, or IDs rather than this kludged solution. IDs would be great, because then we wouldn’t be ruining the purity of the Layer name. But since Layers typically don’t show up on any documentation, this corruption of the name isn’t a big concern for me. It should actually help someone who receives a DWG from me, or takes over the file, because the Layer name has extra data which helps explain what’s going on. If I went down the route of Layer as IFC data, this numbering system would clearly pose an issue. But I’m not there yet, so that’s a non-issue too. Of course, I am curious: because of the way IFC is set up, would it naturally create similar categories—categories that could be further enhanced with the locked, hidden Layer as title/header concept?
Who sees your Layers?
Unless your Layers are about IFC or some other external issue, they should be about the ArchiCAD user. So let’s make them better. Don’t avoid this concept because it feels like a misappropriation and a work around. Embrace it because it adds more logic, order, and data to your file. Co-opt this because it is a better BIM solution than just doing it the old way (if people don’t believe me, I’ll write another article about why that is 100% true).
To explore these Layers yourself, download my template and poke around. Hopefully this concept is something you can directly import into your company template, adapt for your current layering system, or otherwise use as inspiration. It’s worth noting that if you rename all your Layers, it won’t negatively affect your template/project. I reworked my Layer names without ill effect and also updated one of my current projects with no complications. If you choose to replace Layers in an existing project with your new layering system from your template, make sure that:
- Your project follows your current template’s previous layering system (otherwise problems will ensue).
- When you open the Attribute Manager to replace the Layers, make sure you choose “by index” number. For more on using the Attribute Manager, start here.
Are you following Graphisoft North America on Twitter? Click Here to keep track of all the latest ArchiCAD News in North America (and beyond).