Modeling
About Archicad's design tools, element connections, modeling concepts, etc.

Community Feedback: Graphic Overrides

Ferenc Traser
Graphisoft
Graphisoft

Hi Everyone,

 

Our Product Managers are looking into possible improvements regarding Graphic Overrides. To help them here are a few questions. Any valuable insight is greatly appreciated.

 

  • What is one thing that you would definitely improve on the way Graphical Overrides currently work?
  • How many Graphic Override rules and combinations do you have in a typical project?
  • If you have many rules and combinations, how do you structure them? For example do you put numbering at the beginning of their names or add rules or combinations as separators?
  • How often do you need to manage rules or combinations? For example is there a BIM Manager who sets them up at the beginning of the project or do you need to edit them constantly?
  • If you need to edit them constantly, what are the typical reasons?

 

Thank you!

26 REPLIES 26
Dendarii
Booster

Hi, some upgrades to GO's that would be great:

 

- Distinguish between 'Cut' and 'Uncut' line types (and add 'skin separator' lines option).

 

- Allow graphic override of individually selected elements (or group of selected elements).

 

- Add ability to 'Hide' element/s.

 

- Add ability to override individual lines (cut and uncut).

 

Thanks!

Architect

Archicad user since 2001
abdelaziz
Expert

Hello

What is one thing that you would definitely improve on the way Graphical Overrides currently work?

1- Detect rules that are not used in graphic override combinations

2- Detect combinations of graphic overrides not used in views

3- Retrieve the selection criteria set saved from the "search to select" menu in the GO selection criteria and "in the nomenclature selection criteria" , we save criteria that is only used for a "find and selection" menu 🤔

4- please add additional option that allow to retrieve ZONE category colors in SURFACE Color 😭

5- in the case where I mask a 3d contour, it is impossible to redisplay it by another rule 😭, it would be nice to have a solution to this behavior

6- it would be nice to be able to use the GO on a worksheet generated by the Archicad model, any limit exists to be moved 😅

How many Graphic Override rules and combinations do you have in a typical project?

 

a hundred rules and around fifty combinations

If you have many rules and combinations, how do you structure them? For example do you put numbering at the beginning of their names or add rules or combinations as separators?

 

structure by type of deliverable yes a use number + name deliverable

 

How often do you need to manage rules or combinations? For example is there a BIM Manager who sets them up at the beginning of the project or do you need to edit them constantly?

 

as the project is constantly evolving from phase to phase and the client requirements are variable so we need to edit them constantly

If you need to edit them constantly, what are the typical reasons?

we work with several design offices with specific graphic requirements on different projects, and sometimes the graphic requirement comes from the project owner architect 

AMD Ryzen 5950x
AMD RX 6750xt
AC27

Graphic Overrides is intuitive as a concept and outstandingly potent as a feature. It is used to aid modelling, to analyse the design, to audit the model and to delivering information. It is obviously limiting to think of it as simply a way to override a certain view and base the development on how we currently use it. It need to be considered a integral part of the interface and developed to support not yet implemented workflows.

 

Anyways. I find that the current implementation presupposes a rather rigid workflow and becomes unwieldly as soon as one wants to make changes or use it in a more flexible way. There are especially two basic propositions of which the current implementation seem ignorant:

 

An identical graphic style is often used for multiple rules.

Currently graphic style is jointly defined with criteria to create a style which means that there is a one-to-one style-rule relationship. So if the same style is to be used for multiple rules it has to be defined multiple times. Apart from the obvious inefficiency it also makes overviewing hard and increases the risk for inconsistency especially when changes is done to the style.

 

Instead styles should be defined independently and just referenced in the rule, enabling a one-to-many style-rules relationship.

 

An identical sub-set of rules are often used for multiple combinations.

Combinations is what ultimately determines the view specific graphical reproduction of the model. Multiple views often has the same graphic base but with variations "on top" depending on different situations. For example QA processes which have a base 2D/3D representation of the model to which different aspects are highlighted across different views.

 

Currently combinations are nothing more then a list of rules. This means that if a set of rules is to be used for multiple combinations then the rules has to be added to each combination’s list and if any change is done for the base view it has to be done for each combination.

 

Instead a combination should be able to inherit the rules from another combination.

 

In addition to the efficiency gain this would also lend it self to organisation and open up to a interesting new approach where a tree structure is used as a interface for controlling which rules are applied. This would be useful when working actively in the modell.

thesleepofreason_3-1667042523316.png

Additional basic functionality:

  • A UI which gives a better overview and allows for efficient management.
    • Ability to apply changes without closing the dialog.
    • A pane for rules allowing drag and drop. 
    • Indication of relationship between styles-rules-combinations.
    • Filter rules used in any combination and combinations assigned to any view.
    • Add multiple rules to multiple combinations at once.
  • Criteria
    • Harmonise across the application and make criteria sets globally available.
    • Ability to list and select elements affected by rules.
    • A constant effort to increase criteria domain - all element parts and data should be available.
  • Styles
    • Override every category of graphical elements so for lines cut, contour, in front of projection plane, behind projection plane, hidden, symbol, etc.  
    • Override surface with zone category color.
    • Override pen width.
    • Typographic overrides.
    • Scale dependent variants of rules. Additional variants could be a way to integrate/replace the functionality of pen sets. 

Advanced functionality

  • Ability to have variable styles based on property value. Currently we can select elements and apply a constant style. A powerful function would be to select elements and then apply a style that varies based on a given parameter. So criteria would be used to select elements and then a relevant property would be selected based on which a part of the style would be varied. This would in many cases remove the need for creating multiple rules and it would also give easy and quick access to new insights when analysing the design.

@gavinNZz wrote:
  • What is one thing that you would definitely improve on the way Graphical Overrides currently work? GO should provide the ability to toggle visibility of an object. i.e. make it disappear entirely. This would turbocharge GO into a much more powerful tool that would allow the visibility of elements to be based on properties as opposed to just using layers. The renovation filter already does this in its own way so surely extending this to GO is not a leap too far? 

We desperately need better control of element visibility but I think that there is a risk to make things even messier if it is integrated in GO. Isn't there a distinction to be made between what we want in a view and how we want to view it? Perhaps a invisible style that keeps the element in the view but hides any graphical representation of it?

@thesleepofreason You may be interested in the visibility aspect I have posted in the other GS feedback thread... https://community.Graphisoft.com/t5/Design-forum/Component-Level-Design-Workflows-Conversation-amp-f...

Apple iMac Intel i9 / macOS Sonoma / AC27UKI (most recent builds.. if they work)

here is an illustration that might suit your vision 😉

abdelaziz_0-1667069079903.png

 

AMD Ryzen 5950x
AMD RX 6750xt
AC27
scottjm
Expert
  • What is one thing that you would definitely improve on the way Graphical Overrides currently work?  
    • Folders for Rules and Graphical Overrides Combos
    • Being able to read all the data in the model like the criteria available in schedules (GLD Params, all object properties etc)
    • Completely hide an element
    • Combo and Rule inherited hierarchy
    • Override Cut Pens or Uncut lines independently
    • Adjust Fill or Surface transparency but retain the original colour. eg to be able to 'Fade Out' elements in 2D and 3D.
    • Set an element as transparent in a Section / Elevation without having to active Transparent Model display for the whole section/elevation.
    • Override a specific element / component / attribute. Eg:
      • Override only Outside Wall Face
      • Override only material 'Glass' or everything except material 'Glass'
    • Have labels able to read the overridden attribute that is being displayed. eg:
      • A wall has the Outside Wall Face overriden to PF01 - Dulux White on White, placing an associated label is able read that new surface name, not still read the old surface name.
    • A mapping table ability, eg if you had a list of Properties, being able to list out a specific material override for each option, instead of having to make lots and lots of rules.  Especially if you had a 100 or so different things you wanted to map this clutters up the rules very quickly!  Would be especially useful for zones and setting up a list of mapping colours for the different space types.
  • How many Graphic Override rules and combinations do you have in a typical project?
    • 40-50 Combos
    • ~100 Rules
    • If folders were provided we would have significantly more default GO's in our template.
  • If you have many rules and combinations, how do you structure them? For example do you put numbering at the beginning of their names or add rules or combinations as separators?
    • Numbering to visual order, but this is very clumsy.
  • How often do you need to manage rules or combinations? For example is there a BIM Manager who sets them up at the beginning of the project or do you need to edit them constantly?
    • BIM Manager does the bulk of the work setting up the template GO's these then only need limited adjusted by user on the project
    • Users will also make additional GO's and rules to suit the project requirements, once they are setup and working they usually require limited modifications.
  • If you need to edit them constantly, what are the typical reasons?
    • Frequent editing only required when troubleshooting their display.
Scott J. Moore | Fulton Trotter Architects | BIM Manager, Associate, Architect
Since AC13 | Current versions AC23.7000 & AC26.5002 | BIMCloud Basic | Python, GDL, VBA, PHP, SQL, CSS
Certified Graphisoft BIM Manger (2022)
Win 10, i9-9900K, 32GB, Quadro P2200, 500GB NVMe
maro
Booster

Hi Ferenc,

Please, extend GO on Textures setting in Rules
1 - ON all textures (like it works now)
2 - OFF textures for selected Rules
3 - Grayscale texture for selected Rules
For example: ON for New Status like is asigned for Surface, OFF for Demolished Status - without Textures, and for Exist status please add ability switch to grayscale Textures

Thanks

Marek

Camu
Booster

It would be really nice to be able to make graphic substitutions in the composite walls on the layer you want and not all the layers (material)

 

Tibo_L-EDU
Contributor

Rather than answer those specific questions, as I believe most things have been said, I'd like to add some other stuff:

1. 
It would be useful to be able to have multiple GO's applied at once, that way you could set the line thickness of elements in one GO, and based on other criteria have a second GO apply color to a subsection of those elements. That way you don't have to manage multiple GO's that do the same thing just because the color is different.

2.
Following on that, what I described in '1.' is for the moment only really useful with line color and thickness, the same could be extended to fill_type -> foreground_pen -> background_pen
And maybe some others too

 

3. 

This is a very important one I think: the ability to add user defined properties to all element types: not just wall, slabs, roofs... but also things like dimensions. This would allow the properties to be used as a tag system that can be used in GO's to filter down elements which should have different looks in different views, but should be in one layer (because a layer should just be for making things visible/invisible, right now I split a single layer up in as much as 4 sub-layers in order to be able to get my GO's working as I want*).

4.
This one is more of a general design philosophy one that, if done well, fixes points 1-3: 
take a whole lot of inspiration from CSS.
C-cascading -> points 1,2

SS-style sheet -> just GO in general
it's from web dev: things like variables are inherent to the system/ environment of CSS, if some of those could be brought into the GO system, it would fix point 3, and bring a ton of other QOL features into the GO system.

* As my account name implies, I'm still learning and I just found out about 'layer name contains…' which can help a lot with this. That said, using layers is really not an optimal way of organising all of your GO's