A long time ago I wrote about Order and Complexity as it relates to our favorite BIM program. ARCHICAD has advanced so much in the intervening years, especially with the recent addition of Graphic Overrides (GO) and ARCHICAD Properties, that it is time to return to this topic. In addition to being a look back at an old post, what follows is also a continuation of my thoughts from the post Order of Operations: Managing Graphic Override Combinations.
There are four ways order and complexity mix
In my post from 2012, I defined each quadrant as follows:
Low Complexity, Low Order – 2D production without office standards (this could be flatcad or hand drafting)
Low Complexity, High Order – 2D production with office standards, templates, codified rules for how work gets down
High Complexity, Low Order – BIM free-for-all. Each project just happens, with little regard to what came before or comes afterwards
High Complexity, High Order – BIM with office standards, templates, and clear best practices.
I still like those definitions, but they are talking about ecosystems rather than the specifics of ARCHICAD. Within ARCHICAD we can also have all those combinations of order and complexity. Graphic Overrides work best with High Order and High Complexity systems built out of low complexity rules. It’s really straight out of Stephen Wolfram’s A New Kind of Science, which I will forever be a big fan of.
Simple Rules vs Complex Rules
When crafting Graphic Override Combinations and rules, keep your rules as simple as possible. Decide how complicated the Criteria need to be and how much the Override Style changes the elements’ display. It’s easy to add multiple rules, so there’s no need for any one rule to do more than the bare minimum. The image below shows one of the Graphic Override Combinations from my template: 0 Poched, Zones (Empty) – Dark Trees. From the names of the various rules you should be able to tell what each does (both the name and the rule are simple and straightforward). It is possible that I could create the same effect with fewer rules. To do that, each rule would need to accomplish more. But there’s wisdom to letting the complexity be built up by simple rules: simple rules are easy to remix to form a variety of useful combinations. If your Graphic Override Combination functions properly, it’s okay if it has ten or fifteen rules. Graphic Override Combinations provide order, much like Layer Combinations do. Think of the GO Rules like a giant list of Layers, Surfaces, or Fills. You should have tons—or as many as you need. Graphic Override Combinations are designed to both combine and provide coherence to all the Graphic Override rules.
For many of us our first instinct is to unify as many Graphic Overrides as possible, but that is a mistake. Graphic Override rules require a high level of granularity. With so many little rules, the list of rules can get long and unruly; that’s okay. At some point we always have garbage and disorder to hide. The rules list is the place.
While I do encourage simplicity, we also need to look at individual rules in the context of similar rules. In the previous post, I briefly shared two rules for turning elements orange (see below). From a Graphic Override Combination perspective, there is another way to achieve the second image. I could have made a Graphic Override Combination that consisted of a rule for each Tool Type: a rule to turn Objects orange, a rule to turn Windows orange, a rule to turn Doors orange… (I’d show this third option, but I don’t want to waste my time creating that many rules for a simple image). Determining which route to go—a big rule covering many conditions or a group of smaller rules covering fewer conditions—is a balance of order and complexity. Having a rule for each type offers huge amounts of flexibility. But it also creates more to manage and the additional flexibility might be unnecessary. Do we really need to separate each Tool type? Is there a time where we’d want a GO Combination that highlights just Objects and Doors, but not also Windows and Skylights? If we need rules that highlight these elements, there is probably a middle ground where we have a rule for Windows, Doors, and Skylights and another rule for Objects and Lamps. In this example, it makes more sense to have a few rules that cover multiple conditions (some rules with complexity to their Criteria) rather than many rules that cover individual conditions (lots of rules with very specific, simple Criteria). Aim for simplicity, but don’t create unnecessary specificity.
VS
How Many Rules are Necessary?
The intelligent sorting of data is what allows us to use the Override Styles within Graphic Override rules to their fullest potential. Criteria is paramount. You don’t have to exclude elements from an override if another override is going to fix their graphics higher up on the list. The image below shows the elements from my previous post displayed with my uniform line weight Graphic Override Combination. It contains four rules, three of which affect line weights. The Uniform – Line Weights rule is the most generic and is applied first (hence it is at the bottom of the list). The other two rules that affect lines come after and overwrite the first rule. The first rule—Uniform – Line Weight—is very generic and affects all elements on a majority of Layers. The other two are very specific and affect one or two Layers.
If you look back at Pen Sets, Part Nine: Graphic Overrides, you’ll see I have a Furniture – Uniform layer, which included both trees and furniture. That was a mistake. That rule, as simple as it seemed, was still too complex. On the face of things, the two types of data (trees and furniture) feel similar, but they have subtly different graphic needs. I need trees to be controlled separately from furniture. Furniture needs to have a masking fill. Trees need to be transparent. And sometimes I want the trees to be darker than the furniture (gray trees are nice for most plans, but for site plans it’s nice for them to be bolder, maybe even with a light tone). I could keep my original rule that affects the tree and furniture Layers and have a second and third GO rule for changing trees to transparent and another for darker trees/toned trees that I place above the regular override rule on the list. But that description is hard to even understand in written form. It is much easier to have a furniture rule and swap tree rule A for tree rule B as suits my needs.
Note: if you are swapping rules that affect similar elements (switching a rule that makes the tree Layer have gray lines for a rule that makes the tree Layer have black lines and a 25% Fill), make sure to keep the new rule in the same location as the old rule. In general, that will be the right decision for rule order.
Layer vs Layer Combination
We can create Criteria that affects elements by Layer. We can choose is, is not, starts with, ends with, contains, does, does not contain. But we can also set the Criteria by Layer Combination (is/is not). Setting the Criteria by Layer Combination will affect all the elements that are/are not shown in that specific Layer Combination (whether or not that Layer Combination is the one selected in the View). This adds an interesting level of complexity to the mix by allowing us to create Layer Combinations that are not for Views but for Graphic Overrides. By saving a Layer Combination with only a very specific set of Layers turned on (say millwork, interior trim, tile, and floor finishes or exterior walls, beams, columns, and floors) we can then use that Layer Combination to affect display through Graphic Overrides. Looking at my own Layers, I had a hard time coming up with a good example—as I have my Layers grouped with a prefix 1 |, 2 |, 3 |, etc. But I am sure there are opportunities out there where Criteria by Layer Combination using a special Layer Combination created for Criteria purposes is a better route than by Layer. Each offers a different amount of flexibility and specificity. You can also mix Criteria, so think about using a specially made Layer Combination and then an additional Criteria like Tool Type, Structural Function, Position, or Element Classification. It’s worth noting that a Layer Combination you create for Criteria purposes can also be used as a Criteria for Find & Select and Schedules. So a Graphic Override, a 3D View (Find & Select, then show selection in 3D), and a Schedule can all be aligned to highlight/show the same data.
I’ve talked about this a lot with other features of ARCHICAD: make changes that move in concert, but also allow enough flexibility to move things independently. For instance if you have a Graphic Override Combination that creates grayscale plans by using Layers as a Criteria, think about how specific you need that GO Combination to be. Can it be used for all grayscale plans or do you need a separate one for different plan types (ei, grayscale for electrical and grayscale for structural)? And remember not to rely too heavily on one feature of ARCHICAD. If you can get two GO Combinations to almost combine into one, will they work as one with a clever use of Model View Options or Layer management?
Element Type vs Element Classification
Instead of sorting by Tool or Layer, we can sort by Classification. I’ve talked about Classification before—as it relates to schedules—and it’s something I need to return to. Classification allows us to label any 3D element by type regardless of Tool. The element will still act like the Tool that was used to create it, but we can control its data (AC Properties & IFC properties) and sort it by its Classification. We can use the Window Tool to create an element, classify it as a door, and have it appear in our schedules and data structure as a door. It can be affected by our GO rules as if it were like a door created with the Door Tool. Creating Graphic Override rules that look at Classification rather than Tool Type or Layer is wonderful. Here’s another example: we can model a roof out of a Shell, set the Element Classification to Roof and then have a Graphic Override that turns all Roofs translucent in 3D based on Element Classification. This is fantastic because we might also be using the Roof Tool to make a sloped floor. We have that floor modeled with the Roof Tool and classified as a Slab, which we don’t want showing translucent. Or we might have various elements on the Roof Layer which we don’t want affected by our Graphic Override. By using Classification rather than Tool or Layer as a Criteria for our Graphic Override, we can accomplish this separation of data.
Paying attention to Classification and setting up Graphic Overrides to use Classification is powerful but it also adds complexity. It means we need to pay more attention to something that isn’t automatic. It is automatic if we set up our template and always work from favorites; however if a coworker (or you or I) veers off the approved path, errors can propagate throughout the model. Criteria set to find Tool Type rarely misses a stray element—unless it’s a special case modeled with a different Tool (in which case we are typically aware of the one-off and have to jump through hoops to get the particular element to be included). Criteria set to find Classification has a higher probability of error because it requires more vigilance; but that’s the price for more flexible. Verifying that classification is being followed correctly (which could be done with some simple Graphic Overrides that highlight elements by Classification in 2D and 3D) is the sort of task we want to be doing, rather than other labor intensive tasks like outlining elevations with a thick pen weight, manually drawing shadows, or adding 2D patches to incomplete sections.
Using Classification is complexity we want to have. It is complexity worth managing and using. It is good complexity.
Simple vs Complex Lists
The more we explore Graphic Overrides, the more rules we’ll end up with. Because there are so many combinations of Criteria and override styles, the list of rules we have in our files will get very long. This is good. It means we have more tools at our disposal to segment and display our data. As the list of rules and combinations gets longer, we need to develop techniques to keep the items organized. Organization is mandatory.
It is valuable to keep the rule names clear and grouped. Put the function before the target. It’s more important to have all the rules that do similar things together than to have all the rules that affect the same type of element together (with a few exceptions like Zones). Naming should be handled in a way that helps group similar rules—both rules that will be used together (position or structural rules) and rules that replace/build off each other (Cut Fill rules, white model rules, Zone rules). I think in the next iteration of my template, I’ll update the naming of my Graphic Overrides to start with a two digit number (00, 01, 02…)—that way I can better organize my rules in a way that isn’t subservient to the arbitrariness of alphabetical order (which is a system I’ve implemented with Graphic Override Combinations, Layer Combinations, Layers, and many other Attributes in ARCHICAD). That way I can have all my 00 rules focus on Zones, my 01 rules deal with lines, my 02 rules changes Fills, my 03 focus on model auditing, or some such structure like that. All to be determined later. I didn’t create this structure for my current template because Graphic Overrides were still too new. I didn’t yet have a sense of how many rules I’d end up with. I needed to create a loose organizing structure (by first word) to see where my rules were clumping before I developed a more rigid, higher order structure.
That’s all for now, but if you want more…
There are a lot of similarities between Graphic Override Theory and Layer Theory. Both are about grouping and organizing ARCHICAD elements through the use of metadata. In a very general sense, you could reread the following posts on ARCHICAD Layer Theory and just replace Layer with Graphic Override and Layer Combination with Graphic Override Combination. The basic concepts of naming, combinations, types of models, organization, and necessity would apply.
Part 1: LEGO and Layers
Part 2: Do you need that Layer?
Part 3: Layer Combinations
Part 4: Different Kinds of Models
Part 5: Attribute Names and the Tyranny of Alphabetical Order
What other questions do you have about Graphic Overrides? Share in the comments below. Are you following Graphisoft North America on Twitter? Click Here to keep track of all the latest ArchiCAD News in North America (and beyond).