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.
Thanks Ferenc for your kind request, I think it would be super useful to gather some community feedback about different topics as well! This is my first message in the forum but I’ve always wanted to contribute somehow and this seems to me like the ideal format to begin with.
My apologies for being partially repetitive but I would like to add my insights anyway. Indeed, it’s nice to read so many users writing down something very close to my own personal wishlist! Therefore, starting with the implementations topic, I would first of all organize two different categories for across-tools coherence improvements and completely new features:
Coherence improvements: GO should definitely have the exact same avance features schedules already have since many years.
New features: the only one completely new function I think could be a real game changer is a toggle visibility button acting both on elements, hosted elements (windows, doors, holes) and of course hierarchy and BMats components as well. This simple feature, together with the former one, should definitely solve the long time requested phasing tool which would simply become an advanced GO-based alternative to the Reno filter itself with the chance to create as many phases as the user want with a simple group option property activated through a purely GO filter.
Coming to the other statistic questions: I normally have a dozen of GO combinations in my template with more or less 50 rules which I always decline in different projects based on specific needs. Personally I don’t particularly like the numbering way of organizing tools nor separators (I usually delete them when present) since it’s quite complex to manage while the project evolve in time. At the moment I use a two digits prefix code for separating combinations by activities (eg CC for code checking, DC for dimension checking, AF for analysis functions, RF for Reno filter pairing, GR for graphical representation and so on). Maybe I could suggest again to use an already existing structure for internal coherence, I personally like the property manager organization with user created groups and movable order. As a BIM Manager I usually set GO myself in my template as well as in the one of architectural and engineering firms I work with, but, as I wrote before, I think GO should be necessarily modified in every project due to specific needs which cannot be fully predetermined. It is true though, that a standard common base should be set in every template for making easier and quicker to decline rules and combinations.
Thanks for requesting that. It’s nice to know that you guys are interested in getting feedbacks from the huge community of AC lovers all over the world! I look forward to the see your amazing next update.
I tried to use this formula in a property for the elements which allows me to see which zone the element belongs to but I can't use the GO with this property, it would be possible to have a workaround to display the elements that are not assigned to the zone?
I agree with almost all of the above but want to add one thing...
We need to be able to have GO list ALL properties.
For example - the Property for [Glazing area / Floor area = TRUE/FALSE]
We need for GO to be able to access these and use them for auditing in projects.
No, I still don't accept the argument that it slows down users computers - that means the user needs a new computer or alternatively not use that particular GO (if it had worked). Don't limit our options based on what hardware you think we have or how you think we use the program/function - we want to find new and different/better ways of working and this means we need freedom to do so within the program.
They could always mitigate the implied overhead by applying a switch to turn off all the SAM processing that I assume most of us never need to access. Also bear in mind all the settings missing from the GO's are available in the Schedules, so there isn't much defence for their omission.
1) What is one thing that you would definitely improve on the way Graphical Overrides currently work?
Distinction between cut and uncut lines.
GO for renovation-display is in the most cases useless because this distinction is not possible.
2) How many Graphic Override rules and combinations do you have in a typical project?
3) 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?
For rules, I try to sort them according to what they do or for what I use them... so I name it beginning with the same expression, sometimes like 'renovation', fills', 'working model' and so on...
For combinations, I've a numbering system, according to the project phases.
4) 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?
From 5 up to 50 times... depending on the complexity of the planing task.
5) If you need to edit them constantly, what are the typical reasons?
I do it when I realize the rules or combination doesn't do what I need, or I've changed pens, material, layers etc.
Given this feedback request shouldn't we expect a more substantial item regarding graphical overrides on the roadmap? It sure would be disappointing if all that came out of this was an enhancement to organise in groups - especially if it as flawed as it is for attributes.
So I'm bumping this as a reminder of the unrealised potential of GOs and what kind of development actually needs to be done rather than superficial quick fixes branded as new features.