Order of Operations: Managing Graphic Override Combinations
From the General to the Specific
Graphic Overrides (GO) offer a great diversity of output, are easy to create, and easy to maintain. I’ve previously written about Graphic Overrides as they relate to Pen Sets and to varying output for standard drawings.
The first post above focuses on individual Graphic Overrides—how to set up criteria and how single rules affect elements by changing their colors, line weight, line type, and Fill patterns. The second post talks about how Graphic Override Combinations work with other View Settings (Layer Combination, Model View Options, Scale, etc.) to create a variety of standard drawing types. This post will look at Graphic Override Combinations themselves and how they relate to Graphic Overrides.
Graphic Overrides are to Graphic Override Combinations as Layers are to Layer Combinations
Different Ways of Looking at the Data
Let’s look at a group of elements and see how Graphic Override Combinations affect them. To keep the following exploration complete, let’s start with no overrides. Graphic Override Combinations are unique in ARCHICAD because there is a “No Overrides” option. We can’t disable Pen Sets, Model View Options, Layer Combinations, Scale, etc. We must always have something selected. We can’t have NO Scale or NO MVO—though we can have many of these set to the dreaded Custom. Graphic Overrides however can be set to No Overrides. This means we see the elements in their natural state. It also means this feature can be completed ignored, if you so choose. But don’t do that. I can’t fathom not using Graphic Overrides. Graphic Overrides were one of those features that once I used them, I had to have them at all times. I can’t ever go back to using a version of ARCHICAD that doesn’t have Graphic Overrides. This militancy doesn’t happen ever version. I always prefer to use the latest version of ARCHICAD, but it’s not always that I won’t go back. Though to be honest, I had a similar reaction when I started using ARCHICAD 19. So maybe this is the new normal? Maybe. Anyways, I digress. We can set Graphic Overrides to No Overrides, but the only reason to do this is for auditing a file, for checking the model’s baseline.
When looking at the image above showing the elements with no overrides, the thing that should be jumping out at you is the horribleness that is the chair. The hatch is all messed up. That’s okay. As I’ve discussed elsewhere, furniture is something that has its graphic display always handled by Graphic Overrides. The chair is a clear example of an element that is ALWAYS controlled by Graphic Overrides (you can see an early version of the settings for this Override in this post). Since the 2D display of this element (plan, section, and elevation) isn’t affected by the element’s settings, I completely ignore the element’s 2D settings. There’s no need to set them because they’re never used. Instead all furniture is globally controlled in unison. I also have a Graphic Override that turns the surfaces of all furniture to translucent. If I use this in a project, I can also ignore the Surfaces settings for these elements. The reason I have this translucent GO is because sometimes I want to show furniture but not waste my time picking cushion colors or making sure the wood of the table matches the wood of the chairs… BTW, if you do need to worry about furniture colors in 3D, the Surface Painter is the way to go.
Next let’s look at the elements with my default override settings for construction documents. You won’t notice much changing, other than the tree and the chair now look the way I want them to. The different between these two images highlights that for the majority of elements, we still need to set their 2D settings properly as for typical drawings like architectural plans, sections, and elevations these element based settings will matter. I’ve played around with setting up complex criteria that will change the color (or Fill patterns for those not switched to color drawings yet) of individual elements based on ARCHICAD Properties, but there are currently a few drawbacks to this solution. We can’t change only portions of an element (so we can’t change the Fill color of the window frame to gray and the Fill color of the window trim to brown, or just the glass line to a thinner lineweight). The same goes with Surfaces. We can override all the Surfaces in an element, but not just one. This means trying to control all 2D (let alone 3D) output with Graphic Overrides adds too much complexity and limitations. Instead it’s better to focus on where Graphic Overrides decrease complexity and increase control.
Schematic plans are a good example of where the universal changes of Graphic Overrides shine. Since we want elements to end up with matching fills, pens, and colors, a simple Graphic Override Combination does the trick: So far the Graphic Override Combinations I’ve shown aren’t anything new. In fact I covered those settings in this post. You can also explore them in more depth by downloading my template and look at the Graphic Override Combinations 1 Default, Zones (Empty) and 0 Poched, Zones (Empty) – Dark Trees.
A Study in Blue and Orange
Now let’s have some fun and look at these elements with a bunch of different rules designed to highlight how to organize Graphic Override Rules into useful combinations. When creating a Graphic Override Combination, it’s important to remember that the rules are applied from the bottom up; rules higher on the list will override rules lower on the list. Order effects display. For instance if we have a rule that changes all Objects to orange but it’s below a rule that turns all elements to blue, Objects will be blue since the rule that turns all elements blue is applied after Objects are turned orange.
Our rules might be correct, but if they are in the wrong order, our results will be incorrect. With our example, if we move the rule all Objects to orange above all elements to blue, all elements would be blue, EXCEPT Objects, which would be orange.Notice that the door and window are still blue because while Objects, they weren’t created with the Object Tool. If we really wanted all Objects (regardless of Tool) to be affected, we would need to create a separate rule for each Tool type or create a more complex rule with criteria that included Objects, Windows, Doors, Skylights, Lamps, and any other Tool type that references an object in a Library. Below are images showing the difference between the display and rule for all Objects, regardless of Tool and all Objects Tool elements. These images are also a good reminder that even if you only want to apply one rule, you still need to make a Graphic Override Combination for it:
Now that we understand order, we can tweak rules to create other combinations. If we change the Objects to orange rule to only change their Lines, we can use these two rules to make all elements have a blue Fill and then make Objects also outlined in orange. The first rule affects all elements and the second rule (higher on the list) adds another override to a subset of elements.
We can also mix what the two rules affect; we can have two rules both altering Fills. In the image below my blue rule turns everything blue and changes the Fill type. The orange rule just changes the Fill Background Pen of Objects. You’ll notice that there’s some weirdness. The sink background didn’t change to orange and the light switch Object isn’t affected by this altered rule because it doesn’t have a Fill associated to it that can be changed.
It turns out if an element’s Fill Background Pen is set to transparent, Graphic Overrides won’t override it. I never saw this behavior until I started writing this article. I have an email out to tech support to see if this is a glitch or by design. I have a feeling it’s by design. That’s okay. There are ways around this situation. Make sure your elements’ Fill Background Pen aren’t by default set to transparent if you need to control their background color; pick Fills that are solid due to their Foreground Pen (this is why we have a Foreground Fill and a Background Fill by default); or control transparency by Graphic Overrides by making your elements solid by default and transparent through the use of rules.
Always Check Your Work
This weirdness discovered in my two simple rules is a nice reminder to make sure to review your Graphic Override rules and Combinations. When creating rules, we must test them individually to make sure they are working before we combine them (think back to the brief aside about changing Objects to orange or changing elements created by the Object, Window, Door, Skylight, or Lamp Tool to orange). Once we know an individual rule works by itself, we can then test how it interacts with other rules. If we don’t do this, how the rules are ordered in the Graphic Override Combination might disguise a deeper flaw (if we haven’t first checked the rules, how can we know whether a display error is caused by the order of the rules or the rules themselves?). I recommend checking two or more drawings to verify everything is displaying properly. Once you know a new Graphic Override Combination works, mess it up to make sure it works wrong when it is wrong. Sometimes that doesn’t happen. Also mess up the model to make sure it works properly when the GO is right but the model is wrong/weird. Why? Think of it this way:
If we want to make a GO Combination that highlights certain errors, we don’t want false positives. That means making sure the GO isn’t coincidentally giving us the correct answers and that the model is responding properly. For instance if we’re looking at structural position (interior/exterior) what happens when it’s undefined? Or if the GO is looking at a property, what happens if the property text is misspelled? Will the GO flag that?
This might sound like a lot of work, but remember Graphic Override Combinations must be part of your template. Any work done on Graphic Overrides needs to start in your template or be folded back into your template for future projects. This tedious testing and checking benefits not one project, but all future projects. This vigilance and support of template building is why BIM is making your firm more profitable than ever.
Surprise, this is about Data!
We need to be extremely careful about the results of our Graphic Override Combinations. Minor errors might not seem like a big deal for 2D graphics, but Graphic Overrides are about much more than just simple visualization for printouts and 3D views. Graphic Overrides are about visualizing data; they allow us to quickly interpret and parse data. A GO that separates out structural vs non-structural elements is easy to examine and scan for elements that are incorrectly classified. And once you know your data is correct, then you can have confidence sending out an IFC model to the structural engineer. Or doing a quantity take off for concrete. The same goes for any sort of data. Imagine giving all your elements a cost value and then creating a Graphic Override Combination that color codes elements by cost. Your rules are: below X is green, between X and Y is yellow, above Y is red (and gray for No Data/Zero). This would be a quick way to find areas of high or low value. It’s doable today in ARCHICAD, if you set up the proper Graphic Override rules and combination, and then pay attention to your data to make sure the results are telling you something useful.
Graphic Overrides allow us to verify that our data is correct, and verified, accurate data is what the future is all about.
What are some of the weirdest Graphic Override Combinations and rules that you’ve come up with? 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).