AEC design tools are typically designed at one of two opposing ends of the spectrum:
The former is ideally suited for free-form concept iteration and complex modelling, whilst the latter is more rigid in its data-driven approach and leans more towards production, documentation and analysis practices.
Both have their own uses at the most appropriate time, and the reality is that both can and will be used at the same time. The ability of our teams to use both at the same time is limited by inflexibility of the tools, and so workarounds are often required. The most common practice is to establish a “cut-off" point at which a project will move from geometric-centric model to object-based; often necessitating a significant level of reproduction of information.
Beyond this, object-based modelling tools – an enabler of modern BIM approaches – are limited in terms of the intelligence with which objects can be assembled. We, as designers, understand the rules, relationships and parameters that govern our projects through all scales – from building down to element. Our tools do not currently have this logic, and so pose a limitation on what our design teams can achieve.
Regardless of modelling approach, the industry also finds itself having to rebuild or export models for parallel processes such as analysis, visual representation, or documentation. This approach starts to fragment the design process, resulting in inefficiencies and miscoordination.
The ability to efficiently model with increasing accuracy, flexibility, detail and intelligence.
Software should enable design, not control it through its limitations. There are key modelling functionalities that enable good design software:
Modelling tools should be an accurate reflection of construction and should allow design teams to create models that have an appropriate level of accuracy depending on scale, project stage and proposed construction.
Project teams should not have to decide between geometric flexibility and complexity or object-based modelling. Future architectural design software should strive to embrace and connect the two approaches, offering an environment where designers can nimbly navigate between the two. The process of transforming a geometric study into a comprehensive, data-rich building model should be a fluid progression, reducing the risk of information loss and eliminating the need for time-consuming processing of geometric data. This would involve intelligent conversion systems that can interpret and transition geometric models into object-oriented ones, retaining original design intent while proposing appropriate object classifications and data enrichment.
Level of detail
Future modelling tools should be able handle increasing levels of detail, without sacrificing performance or efficiency. Teams should also be able to cycle through different levels of detail, depending on a specific use case.
A new generation of tools needs to push beyond the current standard of object-based modelling. Project elements – from whole buildings, down through assemblies, to individual elements – should host data relating to assigned identities, key attributes, constraints relationships, and associated processes. This embedded data should be based on real-world information, providing a reflection of the knowledge and information that the AEC operates with.
Software developed with this balance and understanding of basic construction principles can also benefit from intelligence and efficiency gains, such as resolving basic modelling connections/ details and amending repeating elements and data/ information en masse.