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.
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.
here is an illustration that might suit your vision 😉
Still looking?
