KINDAutomatic, which launched in beta this month, aims to streamline BIM workflows by offering Revit users and AEC software developers a faster, more intuitive way to access data in Revit (RVT/RFA) and IFC files — bypassing the need for traditional desktop software.

The cloud platform delivers a ‘comprehensive set of tools’ for extracting, processing, and parsing BIM data.

Through API integration, data can be seamlessly fed into existing software, while custom workflows enable the automation of data extraction.

According to the company, its scalable cloud platform can extract data from Revit and IFC files up to 10x faster than conventional methods.

Users can extract views (PDFs and SVG), Geometry (IFC and glTF), and Metadata (JSON). Files can be viewed directly in the UI, with a full breakdown of geometry and metadata.

Meanwhile, with ‘advanced filtering, users can filter and query BIM data without having to ‘wade through irrelevant information’.

Extracted data can also be pushed to third party tools such as Speckle (for real-time collaboration) or AWS IoT TwinMaker (digital twins).

The post KINDAutomatic to liberate Revit data appeared first on AEC Magazine.

Trimble SketchUp 2025 features better interoperability with Revit and IFC, and new visualisation capabilities, including photorealistic materials and environment lighting options.

To improve interoperability the 3D modelling software now includes more predictable IFC roundtrips, greater control over which Revit elements and 3D views are imported, and improved support for photorealistic materials when exporting USD and glTF file formats.

“The IFC import feature is incredible,” said Lucas Grolla, architect and owner of Grolla Arquitetura. “It has greatly improved the coordination of different project models with the architectural design. Plus, the new material editor and HDRI styles open up countless possibilities for the visual representation of projects.”

According to Trimble, the new visualisation features enable designers to apply photorealistic materials, turn on environment lighting and see how they interact in real time without hitting a ‘render’ button or waiting to see changes.

For enhanced environments, 360-degree HDRI or EXR image files now act as a light source, reflecting off photoreal materials. Meanwhile, dynamic materials are said to more accurately convey texture and represent how real-world materials absorb and reflect light, with a view to producing richer, more realistic visuals within SketchUp. Finally, the introduction of ambient occlusion adds visual emphasis to corners and edges, adding perceived depth and realism with or without having materials applied.

“Accessing high-quality, realistic materials directly within the platform has made it so much easier to quickly present designs that resonate with clients,” said Kate Hatherell, director of The Interior Designers Hub. “This feature is a game changer for accelerating workflows, and I’m excited to see how it continues to evolve.”

Elsewhere, LayOut, a tool for creating documents from SketchUp models, has been updated to provide a user experience more consistent with SketchUp. 3D Warehouse, a vast repository of 3D models, also now offers curated photoreal materials, environments and configurable 3D assets in the SketchUp content library.

Find this article plus many more in the March / April 2025 Edition of AEC Magazine

Subscribe FREE here

The post SketchUp gets viz and interoperability boost appeared first on AEC Magazine.

Cesium, a specialist in 3D geospatial technology, has launched its AECO Tech Preview Program, with the aim of improving workflow and capabilities that place architecture, engineering, construction, and operations (AECO) content in a 3D geospatial context.

The company has made two new technologies – Design Tiler and Revit Add-In – available for early access, to transform IFC and Revit files into 3D Tiles, an open standard developed by the Cesium team for streaming and rendering massive amounts of geospatial data.

AECO 3D Tiles includes metadata for querying, filtering, styling, and analytics, for efficiently streaming massive datasets to the web or through project-centred applications via Cesium’s geospatial platform.

According to Cesium’s Dave Braig, with IFC data as 3D Tiles, there is greater performance, increased interoperability, and less manual effort to optimise this rich content for viewing and distribution. 3D Tiles from Revit files include the metadata, materials, and textures.

Cesium has been testing these capabilities with AECO projects containing over 4 million individual objects and 800 million mesh triangles.

3D Tiles are compatible with Unreal Engine, via the Cesium for Unreal plugin, which allows developers to stream, visualize, and interact with large-scale geospatial datasets in real-time within the Unreal Engine environment.

3D Tiles are also compatible with Unity, Nvidia Omniverse, Bentley Systems iTwin platform, and other engines / platforms.

The post Cesium to connect AECO with 3D geospatial appeared first on AEC Magazine.

As far as interoperability is concerned, from the get-go, the BIM software sector did not cover itself in glory. If you think about it, that’s bizarre, for an industry which, by its very nature, requires data to flow between fragmented, multidisciplinary project teams.

The problems created by a lack of interoperability were hardly unforeseen. In 1994, the International Alliance for Interoperability (IAI) was set up by Autodesk to define Industry Foundation Classes (IFC) to aid data exchange. But when it came to conforming to IFC standards, even Autodesk itself didn’t do a great job of achieving that goal for decades.

The 2D world eventually coalesced around Autodesk’s DWG, after Autodesk’s competitors all had to reverse-engineer the CAD format. But the move from drawings to new model-centric, proprietary formats like Revit’s RVT set data exchange back ten years – unless, of course, you were all using the same software.

The net result is an industry where applications support various incarnations of IFC, to various degrees of quality, and customers don’t know what they are doing with it. Customers in some countries, such as the US, have just opted for everyone to use one solution from one vendor, and put RVT as a deliverable in their contracts. This, of course, has been great for Autodesk and its shareholders.

As we shift from BIM 1.0 desktop filebased systems to BIM 2.0 cloud-based apps and databases, the whole competitive landscape is set to change once more. The propensity for the industry to keep breaking compatibility is always there, but this time around, something odd is happening. The main vendors are talking about data openness in a way they have never done before, as if it’s central to the next generation of tools.

Given the industry’s history of using proprietary lock-in as a business advantage, this sets off my spider senses. But facts are facts. Bentley Systems has open sourced its next-generation database format iTwin and is available on Github. Market leader Autodesk is also preaching open standards and signing deals with competitors to allow API and APS (Autodesk Platform Services – formerly known as Forge) access. The company has already done technology swaps with PTC, Bentley Systems, Ansys, Cadence and Trimble and is championing and looking to BIM-ify Pixar’s Universal Scene Description (USD) in collaboration with other industry players.

A proprietary world

The truth is the world of CAD goes through cycles of interoperability. Typically, when a software company creates a new desktop design tool, it would develop a file format, or schema, in which to save the customer’s data for loading, archiving or sharing.

Every software company has its own proprietary file formats and each one is unique to the application. Autodesk has .DWG and .RVT; McNeel Rhino has .3dm; Graphisoft has .PLN; and Bentley Systems has .DGN – to name but a few. There is nothing wrong with proprietary or native files, as all applications need to store the data in some structured document type.

With incoherence being built in, the early phases of these new generations of software are the Wild West, as developers duke it out to see who will become the market leader by volume in any market segment; the benefit being that, if you have the most users, then your format becomes a de facto standard. More people will feel the need to buy your software over competing products and that will further drive your format’s dominance, as it’s the most basic, reliable form of interoperability.

The big software battle may move from owning the highest volume ‘branded’ monolithic app or suite to having the most resource-rich, connected design cloud. It will be about where you choose to hold your project information – because customers will bring their connected ecosystems

As total market domination is usually not possible, this leaves competitors with customers demanding the ability to read and write in the de facto format. With some reverse engineering, or by licensing a third-party toolkit, they begin to add support for the market-leading platform. The best historic case in point is Autodesk’s AutoCAD DWG, which dominated the market and still does. DWG is an essential export of any competitive CAD tool.

The problem with convergence on one company’s proprietary format is that all software programmes work differently, have different capabilities and are built according to different concepts. A firm may well have enabled its competitive application to export or import a DWG, but there is a fair degree of internal mapping and conversion of entity types (layers, polylines, linestyles, dim variables and so on) and this is never 100% operable between software with different origins.

After several attempts at including DWG export/import in Bentley Systems MicroStation, but still getting complaints from users wanting enhanced conversion, Bentley took the decision to include all the entity types in AutoCAD in MicroStation, so that data would no longer need to be mapped or translated between the applications. That’s an extreme solution by any measure. The proprietary win in an industry is a very powerful commercial bonus; it means a developer can call the shots and look forward to selling software to supply chains and everywhere its customers touch.

Find many more articles like this in AEC Magazine

Subscribe FREE here

Reverse engineering

Did Autodesk like the reverse engineering and adoption of others of its file format? Not really. In a story that is too long to tell here, a threat arose with the first AutoCAD clone. A CAD application called Intellicad came along, which used DWG as its core format and mimicked AutoCAD’s capabilities.

Autodesk’s reaction was to mimic Coca-Cola’s response to Pepsi, highlighting that only its own products were 100% DWG. Copycats, it argued, simply could not offer ‘the real thing’.

This led to the creation of the Open Design Alliance (ODA), which pooled Autodesk’s competitors’ reverse engineering knowledge of DWG and provided updated libraries (the ODA went on to develop libraries for DGN, IFC and RVT). It was now increasingly hard to work out where DWGs originated from. Autodesk devised a way to throw a spanner in the works by including a copyrighted phrase in the file. This meant that AutoCAD could be programmed to give a warning when it encountered a non-AutoCADoriginated DWG. Somewhat foolishly, the ODA went ahead and copied this copyrighted phrase and was taken to court, made to pay dearly and had to remove the alert-triggering phrase.

Autodesk’s intention was to warn users that a non-Autodesk DWG could be corrupted, planting a seed of doubt and also helping Autodesk support staff to work out if a problem file was ‘not one of theirs’.

Other CAD firms have gone so far as to encrypt proprietary files, making reverse engineering harder. We encountered this with mechanical CAD (MCAD) software developer PTC when, as an incumbent, it came under extreme pressure from a new upstart called Solidworks. Proprietary formats are a form of leverage, but they contain the full fidelity of the authored data. Pretty much all interoperability standards are lowest common denominator solutions and ‘lossy’.

Over time, DWG became the standard file format in 2D CAD-land, and with every competitor providing support for it, data was able to flow. But then along came BIM and the industry went back to square one, with IFC in its infancy and on a slow trajectory. It wasn’t until 2016, after three years of work, that the ODA released its first RVT libraries. However, Revit changes format with nearly every release, thus always needs reworking.

Developer networks

With customer BIM data held inside proprietary files, developers who want to provide additional solutions to customers and work on that data have needed to become members of the main software firm’s developer networks. For Autodesk, this would be the ADN (Autodesk Developer Network), which allows early access for coming releases, access to APIs and support for desktop products.

With a long-term vision in the cloud, Autodesk introduced Forge in 2015, now called APS (Autodesk Platform Services). APS offers a broad range of services that developers and customers can utilise to create new programmes or incorporate services into their products.

For instance, many developers utilise Autodesk’s Model Derivative API for converting file formats (it supports 70-plus of these). While an application may be 95% written by the developer, they can rely on Autodesk’s cloud capabilities to integrate them with Autodesk BIM 360, Autodesk Construction Cloud (ACC) or to access, open and view a Revit file. Other APS services include the Design Automation API and Reality Capture API, which are paid for by Flex tokens based on use. Pricing can be seen here.

In the past, if one of its developers sold to a competitor, that would result in almost immediate ejection from the ADN, which is understandable, since members get early access to the next release. In fact, Autodesk has historically uninvited longstanding, trusted developers from the Autodesk University (AU) event, for offering a new feature that is deemed competitive with one of its own products.

But again, something different is happening now. Firms such as TestFit (which competes with Autodesk Spacemaker) were uninvited in the past, but are now not only being welcomed back to AU, but also being invited to contribute features to Autodesk Forma, the newish cloud version of Spacemaker.

Snaptrude, which is developing an actual head-on Revit competitor, is allowed to use the Model Derivative service to access RVT and was even permitted to take a booth at AU and run a presentation. One of the conditions of use with APS (5.3 in the terms and conditions), states, “No use by competitors — except with Autodesk’s prior written consent. You may not access or use the Services if you are a competitor of Autodesk”. So they could pull your access to the cloud services unless there is prior negotiation.

Open formats

Despite starting IFC and the IAI, Autodesk’s interest in supporting it went kind of missing in the process. With an American-biased view, I can probably understand this, as in the US, Revit is dominant and IFC is hardly required as RVT is the contractual format.

Prior to the release of the open letter to Autodesk, Autodesk had already been negotiating with the ODA about joining to get access to the IFC libraries, which were now the industry standard. Here, conjecture could be that it was cheaper to license the IFC libraries than develop, or perhaps fidelity was on its mind before the open letter hit.

For the ODA, Autodesk joining was a problem amongst its members. It seems that a special membership status was created to allow Autodesk access to IFC alone, but not the other libraries – for which membership states that firms have to give up all they know about DWG and RVT, which would have been a big ask.

The ODA DWG libraries were also updated by members to support multiple processors and other advances that even Autodesk’s technology didn’t have at the time.

USD is the new format in town and owned and managed by Pixar. Nvidia has based its Omniverse common data environment for AEC users on the format.

Essentially, USD is an accurate mesh, with textures and lighting, and lightweight enough to act as a format to bring in large data models and utilise all the cloud GPU power that Nvidia can provide. Autodesk seems to have fallen a bit in love with the format and has been experimenting with it in manufacturing and AEC.

While Nvidia was scraping data from Revit and hiding it inside its USD, Autodesk wanted to force standardisation, so every developer had the same access. The AOUSD (Alliance for Open USD) was born and joined by firms including Apple, Siemens, Ikea, Sony, Trimble and Hexagon. Extensions are being submitted for inclusion to expand USD applicability to hold metadata for various industries and open for all.

Autodesk and Nemetschek

At the end of April, Autodesk and Nemetschek signed a deal, one that was previously announced rather prematurely by Autodesk at AU in November 2023. Nemetschek and Autodesk have agreed to allow data to flow more easily from each other’s cloud platforms and desktop applications. The interoperability is made possible by connecting Nemetschek’s dTwin, Bluebeam Cloud, BIMcloud and BIMplus industry clouds to Autodesk’s industry clouds—Forma, Fusion, and Flow—as well as design solutions through Autodesk Platform Services (APS). This will enable customers and partners of both firms to connect their data and capabilities across the mixed solutions.

Under the terms of the agreement, the Nemetschek Group and Autodesk will provide mutual access to their APIs and industry clouds, thereby giving developer access to Nemetschek solutions including Allplan, Archicad, Bluebeam, Maxon One and Vectorworks, as well as Nemetschek’s relevant cloud platforms, and similarly to Autodesk solutions including AutoCAD, Revit, 3ds Max and Maya, as well as Autodesk Forma and Autodesk Construction Cloud (ACC). This will enable the two companies to improve upon existing data exchanges and open new data-centric multi-disciplinary workflows.

The deal seems very broad, but is also very specific to a range of tools on both sides. The fact that it took so long to negotiate suggests there was a lot of quid pro quo to ensure both parties felt they were getting enough in return for opening access. These are, after all, the number one and two vendors in AEC. Nemetschek has three BIM modellers (Archicad, Vectorworks and Allplan), to Autodesk’s one (Revit). It leads me to wonder whether, if Nemetschek acquired a developer, would it have to add that to this list by negotiation, or is the APS access open to all Nemetschek brands?

So what does this all mean? Autodesk is undoubtedly evolving an open strategy in its AEC market play. I am sure that Autodesk will allocate this to listening to its users, but US firms are just not asking for open systems, as they are in the RVT ecosystem. It’s Europe and the rest of the world at stake here, perhaps, but I feel that the fundamental driver to this open view lies in the destination for the next design platforms: the cloud.

It might not seem like it right now, but the file-based world will eventually give way to interconnected design clouds from vendors, loaded with customer databases of projects. These will need to be granular, portable or accessible, since customers will demand it. The big software battle may move from owning the highest volume ‘branded’ monolithic app or suite to having the most resourcerich, connected design cloud. It will be about where you choose to hold your project information – because customers will bring their connected ecosystems.

The ‘trap’ may be that, by hosting all project data in Autodesk’s new unified database (which is proprietary), there will be big benefits through AI and automation, with layers and layers of geo-referenced information available for analysis. The only way to ‘get your data out’ of this database would be to slice up the database, reverting content back into its constituent native files, which by then, will feel like a move as regressive as going back to DXF.

Openness at NXT BLD & NXT DEV

If you are interested in openness and its future in the AEC industry, please join us at our NXT BLD and NXT DEV conferences at London’s Queen Elizabeth II Centre on 25 / 26 June 2024.

You will have the opportunity to learn about new initiatives and take part in discussions on what the industry wants moving forward.

Industry Foundation Classes (IFC)

Industry Foundation Classes (IFC), originally created by Autodesk but now managed by BuildingSmart, is closely aligned with the STEP exchange format and now has extensive support for architectural and construction entities (walls, doors, windows and so on).

There are three commonly supported variants; IFC: IFC2X3 (ISO standard since 2006); IFC4; and IFC4x3; with 4×4 in development. Since 2020, major work has been put into the restructuring of the core of IFC for IFC 5, in order to expand to accommodate smart buildings, smart cities, digital twins, granular level access, cloud streaming and many other capabilities.

Universal Scene Description (USD)

Universal Scene Description (USD) was originally developed and open-sourced by Pixar Animation Studios to help its multidisciplinary teams share complete 3D ‘scene descriptions’ between a mixture of different software applications. It supports a variety of elements such as mesh geometry, materials and animations.

While it currently doesn’t officially support any embedded BIM data, the Alliance for Open USD (AOUSD), headed up by Nvidia and Autodesk seeks to expand the format to better accommodate the data needs of the industry (www.aousd.org). USD is owned by Pixar but the plan is to make it an ISO standard.

The post Towards open AEC systems appeared first on AEC Magazine.

Maria Lennox has an impressive CV. Prior to joining Datacubist in February 2022 to head up the company’s BIM services, she spent several years as an architect and several more in large construction companies. Her first move was to NCC Sweden where she was given the time to develop how construction companies could make the most out of BIM. Lennox then became BIM director at SRV in Finland.

At NCC, Lennox first assumed that there wasn’t a problem with BIM data – teams make models, other firms use the models – but the reality was a lot more complex. With her small team of BIM experts, they made all kinds of use cases for cost estimators, design managers, site personnel, together with guidelines for designers to meet the demands of construction companies.

After a while the team realised that it was a hopeless effort, providing guidelines and support to engineers and architects to ask them to add information for their use cases, as Lennox explains, “You can’t expect people to add information they are not responsible for. They are not interested in data that a site engineer needs to make a schedule. Even if you request for them to provide the concrete information for the model state, and they do it once, it’s never updated again.

“It’s exactly the same thing with everything else, like classifications or making it possible to pick up an object for purchasing, or cost estimation, it’s always different kinds of classes or needs. You just can’t rely on it.”

In 2016, Lennox started using Simplebim on projects and realised that her team was able to take control of the data inside of the models, so instead of asking people or designers to fix their models or add the extra information, the decision was the reverse – to ask for as little as possible and minimise the expectations!

Instead of trying to maintain 15 to 25 common data fields, the team managed with two or three. Based on that concept, her team added everything else for their own use cases. By creating the data and handling their own data, they could keep control of the model information in the IFCs. Lennox refers to this process as having established internal ‘BIM data factories’ to automate the maintenance of IFC information layers. In a typical month at SRV, Lennox explained there would typically be between 500 and 900 incoming IFC models from all disciplines, being handled automatically by the system, creating models that made sense to the construction teams.

In today’s BIM world, even with BIM standards and quality checking with Solibri, backed up by contractual obligations and national standards, this is still a woeful process. The easy answer would be to just accept that a perfect world cannot be achieved. However, there are tools that can make sense of the madness, as Lennox explains, “It’s a huge advantage, because, after a little work, you’re able to actually control the data yourself.”

Data wrangling

Simplebim offers both manual and automatic methods of wrangling data which is spread out over lots of different kinds of property sets or filtering too much of the same information. Simply create a new standard property set in Simplebim and standardise within that fresh layer, obviously checking for missing critical data. Then let the software pick up quantities.

The first step is to standardise the information properties to enrich the values and select groups of objects to define as assemblies for use downstream. Obviously if you have 900 models a month coming in, even with a team, this isn’t possible, so Simplebim has a scripting capability which drives the creation of these.

On Dropbox or OneDrive all you need is two folders: folder ‘In’ and folder ‘Out’. By dragging and dropping IFCs into the ‘In’ folder, Simplebim will run its automation, enriching the IFC and will save the updated IFC in the ‘Out’ folder. This could be the architectural, structural, electrical, plumbing or MEP models.

I believe that in construction companies, there is a lot of potential waste inside of BIM models because people don’t know how to use it, it’s too difficult

Models can then be loaded into Simplebim for further refinement, such as sections made, new groups created and even more ways to create sophisticated ‘chain groups’.

In an ideal world, Simplebim advises you always to create the same groups in your models, because then they become much easier to use. You can, for example, always add a ‘pre-cast elements’ group, which makes life much easier for the person scheduling the pre-cast elements.

“From my perspective, I believe that in construction companies, there is a lot of potential waste inside of BIM models because people don’t know how to use it, it’s too difficult,” explains Lennox .” The data itself is very hard and it changes every single time. When you move to another project, you get the files from somebody else, knowing the data fields may change. You shouldn’t need to be an actual expert, but should be able to be the site engineer. We just need to be able to use the model quick and dirty, fast, and move on instead of being a BIM expert. And that’s something we are trying to make possible with this [Simplebim] to make it as easy as possible for every single person.”

Be like water

It’s at this point that I am oddly thinking about Bruce Lee and his philosophy about fluidity and being adaptable to change – “Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle, it becomes the bottle. You put it in a teapot, it becomes the teapot. Now, water can flow, or it can crash. Be water, my friend.” It’s much better with Lee’s delivery.

However, it’s important to realise that a lot of the problems caused in BIM workflows, especially in IFC, are to do with errant labelling and missing data. By accepting the nature of the humans who created the models being hosepiped in your direction, Simplebim can turn the roughest torrent of non-aligned IFCs into calm water by automating naming, tagging, and grouping of the models, and building that logical layer.

Using the Simplebim Hub and scripting is an important capability for handling large numbers of models with a high transaction level and getting dependable standard models out the other end. It centralises the data wrangling and the automation takes out the hard work.

BIM-based projects are coming with ever more overwhelming delivery documentation / model requirements. Some are over 300 pages thick and written by people who have had more to do with the theory of BIM than the practicality of what’s actually of use. Having ridiculously high deliverables is simply just going to cost the project more money. The problem is that these are coming from customers advised by academics. The answer is to adopt an open standard deliverable and be like water.

This is the second of a two part article on Simplebim.

Read part 1 here

Simplebim at Hinkley Point C

The construction of Hinkley Point C Nuclear Power Plant in Somerset, England is very much in vogue, with the country caught short in the production of its own electricity during the recent energy crisis. It is one of the most important infrastructure projects in the UK at the moment.

The new nuclear power plant will deliver 3,200 MWe, enough to power six million homes. While announced in 2010, construction didn’t start till 2017 and suffered further delays because of Covid-19, with the latest estimate that it will cost £26 billion to be completed by 2027.

After extensive testing, Bylor (a joint venture between Bouygues Travaux Publics (TP) and Laing O’Rourke) chose Simplebim to manage the build properties of the estimated 30,000 concrete pours over the 50 million reinforcement bars in the project.

Despite having thousands of IFC files, Simplebim automates the cleaning up, mapping and structuring of the data. This lets the Bylor team accurately forecast quantities of materials. And by mapping data to activities in Primavera P6, they can associate material requirements to time. This has allowed the team to more effectively plan resources and manage supply chain and logistical issues. This is important as it also maps to the way that Bylor gets paid, which is by the number of walls, slabs, sofits etc. that it produces. Being able to quantify and track each job feeds into billing, as well as quality management, which on this kind of facility is exceptionally important.

By holding all the engineering data in IFC, the project data is efficiently collated and in a format which can be repurposed to match the daily activity on site. Most BIM tools model objects and entities, which might match the end-product but may be the result of many concrete pours or discrete construction processes. Simplebim provides Bylor with the tools to break the model down to a granular level to define the data for how it will be constructed. In addition, if any changes need to be made due to delays or problems during construction, these can easily be highlighted and updated. All activities within Simplebim are recorded so there’s a comprehensive history log that can help analyse past performance which will enable teams to learn from past experiences.

“This is not necessarily about doing something new. It’s about an making it more efficient, more scalable, less resource intensive, and ultimately more flexible,” explains Terry Parkinson, senior digital engineer, Bylor. “Simplebim allows us to adjust and tweak the information to support our processes. It gives us a level of control that we have never had previously.

The post Simplebim: working with structured data appeared first on AEC Magazine.

The Nordic region was the first place where AEC firms jumped on board with BIM, back in the early 2000s. It was also here that we started to see IFC standards for data exchange taken seriously. SimpleBIM, founded in Finland in 2009, has been a leading player in thWhen the design world was limited to 2D technology, data exchange was pretty simple. The de facto standard was DXF. Once Autodesk’s proprietary AutoCAD format DWG had been reverse engineered, most competitors supported that, too.

Then 3D BIM came along and mayhem ensued. The only neutral / agnostic exchange format was IFC (Industry Foundation Classes). It was embryonic and lacked the kind of data fidelity that the industry expected.

But in the Nordic region, IFC was embraced. It was used as the basis for national standards, long before broad BIM adoption was even on the horizon elsewhere. And one country in particular, Finland, gave us two of the leading IFCbased developers: Solibri, the modelchecking firm eventually acquired by Nemetschek; and Datacubist, the developer of the IFC management tool, SimpleBIM.

Datacubist was founded in 2009 by CEO Jiri Hietanen and marketing manager Sakari Lehtinen. Both had previously worked on the IFC standard at BuildingSmart, the global organisation responsible for developing and maintaining the IFC schema. They also co-authored the Finnish national BIM standards for both buildings and bridges.

Having seen at first hand the mess that firms could get into with BIM data, the pair decided to develop an application called SimpleBIM that would consolidate BIM dataflows for different design disciplines, different software applications and from firms running different data standards.

While IFC is a documented standard, software vendors have different interpretations of that standard and integration can be tricky. On top of that, many users don’t really understand IFC. Many think pressing ‘IFC-out’ is sufficient, without considering what subset of data is actually relevant in the model that they are trying to share. This leads to inconsistent data exchange that can seriously hamper the work of AEC firms collaborating on projects.

SimpleBIM acts as a central conduit for collating BIM information and provides a suite of tools to repurpose, filter and organise project information by making data exchanges consistent and automated.

SimpleBIM features

The first thing any SimpleBIM user needs to do is stop thinking in silos, about silos and where the limits of silos lie. While most industry data is held within proprietary files, the benefits of SimpleBIM come from thinking about IFC as a data bridge, rather than a somewhat troublesome point-to-point data exchange format . SimpleBIM does not damage or remove original data. It just offers tools to centralise, speed up and automate IFC-based workflows.

The product lives up to its name. It has a very basic layout, with dynamic and interactive model viewing windows for displaying basic shaded models, an object data tree, a properties palette and a ribbon bar of in-context menus.

For filtering, trimming and cleaning up IFCs, simply import a model and choose one of two options. You can either drag and drop the objects you wish to keep into the export ‘bucket’ or window; or you can select from the property palette or by storey, in order to produce a filtered IFC exported file.

The next level of capability and automation is to apply templates to transform imported data. Templates are straightforward Excel files, so are easy to create or edit. SimpleBIM comes with a lot of templates, and you will find additional samples online. The software generates a report on errors that occurred during the template application.

Templates can do many things, such as filtering a model to include only objects relevant to a specific analysis, swapping property values, or enriching model data with new properties. It’s also possible to run multiple templates across merged models, all generated from different sources.

Through the ‘Location Prism’ feature, user-defined portions of models can be sliced and diced using clipping planes/ bounding boxes, so that data that was omitted from the model and perhaps needs to be added, such as concrete pours, spaces, apartments, storeys and other construction sections, can be included. Another feature called BIMsheet extracts user-selected model data for Excel calculations or Power BI. This might include, for example, quantities and costings. These are saved with the SimpleBIM data, for reuse. This is a process that has typically been possible only when using the native BIM authoring tool.

It directly addresses the problem of ‘dark data’, hidden away in current BIM systems, since Simple BIM provides tools to extract and analyse data from models that have been merged, even when models have been created according to disparate standards and/or contain high levels of inconsistency.

The built-in BIMCollab BCF Manager for open workflows, meanwhile, enables report creation and distribution with all project participants, from boardroom to construction site. This centralised issue management system generates BCF files from SimpleBIM’s validation reports, highlighting issues in models that need addressing.

Customer uses

SimpleBIM has found favour in construction firms such as SRV in Finland and Bylor, together with consulting firms such as HOK, AECOM, Sweco, Cowi and Ramboll. Benefits claimed for the application include: lightweight models for onsite work, accurate costing of materials and time, model-splitting, automatic classification, a single version of the truth and reduction in time while producing richer models.

Some firms such as Auckland Airport are also using the tool to stitch together a variety of models to be published for postCovid expansion. The model will aid decision-making in redevelopment and ongoing maintenance. Here, SimpleBIM is almost being used as a digital twin.

Conclusion

In BIM workflows heavily dominated by one vendor, mainly Revit, the RVT file is king and delivery stipulated in contracts can be the Revit model. This does differ from country to country, but is especially true in the United States. Either way, it inhibits adoption of open standards.

In countries that have mandated national BIM standards, such as most of Europe, Australia, Japan, South Africa, IFC (along with derivatives such as BCF, COBie) is an essential part of the mix. This also extends to countries adopting international standards like ISO 19650.

SimpleBIM offers a tool that moves the concept of open standards from ‘data exchange’ to being at the heart of project management by offering a suite of powerful mapping, filtering, data enriching and automation tools, to pull clarity out of industry data exchanges that can be pretty chaotic.

Looking forward a few years, platforms like Forma from Autodesk, with its unified databases and cloud-based applications with API access, could bring more interoperability. But today, SimpleBIM and its rule-based classification on file-based workflows is already taking the pain out of wrangling with project data.

This is the first of a two-part article. As a follow on we will look at how SimpleBIM can be used as an aggregator for project workflows and how it can assist in construction.

IFC Special Report – interoperability for AECO

The post SimpleBIM: Taking back control with IFC appeared first on AEC Magazine.

Whether you’re new to IFCs and OpenBIM, or want to dive deep into open source, IFC for infrastructure, or see how the technology is being applied in real world case studies, there’s something for everyone in AEC Magazine’s IFC Special Report, produced in collaboration with buildingSMART United Kingdom & Ireland.

Industry convergence
From sustainability to new business models, and from wellness to emerging technologies, IFC can be a force for good, driving the AEC industry to new levels of achievement

IFC: what is it and why is it needed
Emma Hooper, Associate Director and Head of R&D at Bond Bryan Digital, provides a useful overview of the IFC data model specification

Inside buildingSMART
What is buildingSMART and what can it offer industry practitioners?

IFC for Infrastructure
Perhaps the most significant update to the IFC standard is the inclusion of extensions for infrastructure entities in IFC 4.3

Native OpenBIM, and the rise of open source in AEC
OpenBIM can deliver on the promise of a digital world for the built environment where information and data are truly valued

IFC at Hinkley Point C
By Tim Davies, digital engineering manager, BYLOR JV – Hinkley Point C

Tackling the Gen Zero Project
The UK Department for Education’s Gen Zero project showcases how IFC can be used as the underlying data standard for a large, complex project, from start to finish

buildingSMART certification
By Phil Read, program lead at bSUKI and managing director, Man and Machine

Watch Emma Hooper’s NXT BLD 2022 talk on Information Models and the future of IFC. Register FREE

The IFC Special Report can be seen from page 67 onwards

The post IFC Special Report – interoperability for AECO appeared first on AEC Magazine.

Anyone who has used a computer understands that all data is typically stored in files. In the world of CAD and BIM, design data is stored in the proprietary file format of each software developer. These are typically DWG for AutoCAD, RVT for Revit, 3DM for Rhino, PLN for Archicad etc.

Drawings and models have been intrinsically linked with the files in which they are contained, needing management, protection, and archiving – locally or in the cloud. The new thinking around collaborative design is that we should be working in a centralised database instead, and have access to shared design information, at a more granular level. Qonic Atom IFC is a gift to the industry to accelerate that way of working.

Regular readers of AEC magazine, or attendees of our last two NXT BLD conferences in London will hopefully have seen the presentations from Greg Schleusner, HOK’s principal / director of design technology, on how BIM workflows don’t fit the way the industry works and how we need to build a data bridge to connect all the key data silos of information that we create in the design tools we use.

Watch Schleusner’s 2021 and 2022 presentations below.

To a large extent, this work has already been done in the Media and Entertainment industry with the USD format which connects all users and their tools. USD contains geometry, materials and lighting and means scenes can be easily shared amongst users of different applications. Schleusner envisages that, for now, something similar could be done with IFC which supports more BIMspecific data than USD.

To get over the ‘it’s just a bunch of files’ issues, the idea was to break down BIM models into their components and broadcast them to a central repository (this could be local or in the cloud). As each component (wall, door, window, etc.) is added to the design in Revit / Archicad / Vectorworks, Blender BIM (choose your poison), it is broadcast to the repository. This will create an IFC data lake for the BIM design data.

Here, it’s worth pointing out that other tools like Speckle Systems and IFC.JS are contributing open-based tools which operate in this Common Data Environment (CDE) ecosystem.

The benefits of this ‘data lake’ concept are manifold – the design is no longer only stored in a proprietary file format, IFC components can be selected and shared as work packages with other users and sent individually (vs sending the whole model), users who subscribe to IFC components can be notified when they have been updated and, when the data is out, it will be possible to run applications directly off this common data, as opposed to having to write them for individual design tools.

Using IFC as a core schema already opens up the potential to wire up the existing ecosystem. However, there is one small problem. How do developers ‘atomise’ their BIM data? It’s that issue which Belgian BIM software startup Qonic has addressed and is giving away to the industry as Atom IFC.

Qonic Atom IFC

Qonic Atom IFC is an open-source tool, available on github. It will ‘atomise’ (split) monolithic BIM data into bi-directional streams of BIM components. It can be used to split or recombine IFC and contains the ability to track and log changes to each component as a design evolves.

For his NXT BLD 2022 presentation Greg Schleusner used the early beta of the Atom IFC toolkit to write an integration for Revit. He demonstrated Revit dynamically sending atomised IFC data to another Revit user in real time. When he edited his model, the elements impacted in the other Revit session almost instantly, enabling new ways of working.

With Qonic Atom IFC available as open source code, all it would take is for vendors to write an integration to add this capability. But, as Schleusner demonstrated, it’s something that anyone with basic API knowledge could do themselves, so this doesn’t ultimately have to come from the software developers but can be retrofitted by knowledgeable individuals using tools already included.

Who does this help?

AEC Magazine asked Qonic why it decided to open source an important part of its forthcoming BIM solution (which we explore in this AEC Magazine article).

Co-founder, Erik de Keyser explained, “Our point of view is that we need this capability anyway. If we were the only one to do this, we would then have to convince the whole market, and that’s very difficult. We also think that if we didn’t do it, in six months to two years someone would push the same idea into the market. So, we preferred to deliver a technology that we know really works well.

The next revolution requires a ‘fit for purpose’ core data schema, on top of which both old and new BIM tools can co-exist, protecting investment in current tools, while enabling new, more open ecosystems to grow

“We are using the same technology in our own product, but Qonic will bring additional capability to the modelling and the management sides of BIM data. So there’s a lot of functionality that we will deliver on top of Atom IFC, but it is beneficial for us to give away something that everybody can use, because it immediately opens the market.”

Head of Product at Qonic, Tiemen Strobbe, added, “The initial idea of Qonic is that you bring in an IFC file, and you add further detail to the model and you will have an enhanced IFC file as an output. During the process of enhancing the IFC file, things will change in the model. Designers will send you new designs and, if each time you had to re-import the entire thing and send across 100 – 200 MB IFC files, that’s not really a collaborative workflow.

“For us, it’s in our benefit to have a system like Atom IFC, where you can send across small chunks of the model, just the objects that change and merge it into the rest of the model. We needed to support this kind of workflow, and we feel it needs to be open.”

By making Atom IFC open source, Qonic accepts that its development will be not just down to its team but will be driven in many new directions by the community. Strobbe explains, “Everybody can contribute changes and can merge these changes into the main code stream, or opt to keep them separate. Sometimes people branch off the code stream for their local use, and that’s fine, they don’t have to send their changes to us, or they can choose to contribute to the open Atom IFC code. These can be merged to the main code stream. If we make changes, if we make optimisations, we will push them to this open repository too. Basically, anybody who knows C Sharp can contribute to this to this library.”

Conclusion

Over the last few years, AEC Magazine has been examining what comes next for BIM. There are growing demands from users for a new generation of tools which are not primarily designed for the production of drawings, which all current BIM tools have been.

Mature BIM customers want tools more capable of meeting their modelling needs, together with built-in collaboration capabilities for a disconnected industry. While the concentration of this has been on demanding brand-new tools, we are rapidly coming to the conclusion that the next revolution requires a ‘fit for purpose’ core data schema, on top of which both old and new BIM tools can coexist, protecting investment in current tools, while enabling new, more open ecosystems to grow. Qonic’s generosity has potentially kick-started this journey and IFC looks set to be amongst the first BIM data formats to embrace entity-based file transactions.

Greg Schlusener has launched a website where his views and developments in this area can be seen, together with some explanation videos of the concepts he is working on.

Atom IFC features

• The Atom IFC library is open-source, available under an MIT licence, and will remain so forever. C# library with IFC classes and read/write support.
• Combine IFC objects from different files, while correctly handling all the corresponding relationships, attributes, and properties.
• Merge partial IFC files per building storey.
• Keep track of how many objects have been added, changed, and removed during merge.

The post Qonic Atom IFC – ‘component-level’ BIM data sharing appeared first on AEC Magazine.

What a lovely combination of circles, rectangles, squares, octagons, and an inverted triangle there is in the diagram left. It sort of reminds me of a kid’s shapes exercise from school. But of course it’s much more than that; it’s actually a diagram showing how to represent what we do in the AEC industry in a digital way. In this article I’m going dig a bit more into what each part of the diagram means.

IFC is like an onion

IFC has layers, and once you start to peel those layers back, it might make you cry if you don’t know what you’re doing.
Each layer builds upon the layer below, so I’m going to talk about each layer in the opposite order than shown in the diagram. The list below is ordered from most generic layer to the most specific layer:

• Resource Layer
  Generic things not specific to AEC
• Core Layer
  The most basic things in AEC
• Shared Layer
  Things common to many disciplines
• Domain Layer
  Things specific to one discipline

Let’s go through each layer.

Resource Layer

This is where the basic building blocks live, and I mean the absolute basics.
For example:

• Units definitions
• Shape / geometry
• Date and time descriptions
• Money and currencies
• Property data types

Almost none of these things are specific to AEC. A lot of these things could apply to almost any other industry in the world.
There are some hints of our industry though. For example, there’s a bunch of structural loading objects which are only really useful for structural engineering.

Core Layer

Again, a lot of the things here are still very generic. Here we have basic objects, property sets, and different types of relationships, all of which could apply to any industry.

In this layer you have lots of lovely academic language like:

It captures general constructs, that are basically founded by their different semantic meaning in common understanding of an object model.

That’s not to understate its importance. Like everyone in AEC knows, every building starts, literally, with a good foundation to build upon. The Resource and Core layers are the digital foundations for the AEC industry.

Shared Layer

This is where things get more down to earth and contains the most common objects in AEC. It’s in this layer you’ll find physical things such as walls, stairs, windows, fasteners, earthworks, and MEP fittings. There’s also some broad things such as definitions for management and facilities, such as permits, cost schedules, furniture and occupants.

Domain Layer

Finally, the Domain Layer is where the discipline specific things live.
As of version 4.3, IFC covers a lot of disciplines. These disciplines are:

• Architecture
• Building controls
• Construction management
• Electrical
• HVAC
• Plumbing
• Ports and waterways
• Rail
• Road
• Structural
• Tunnel (work in progress)

I’m sure everyone can agree this is a pretty extensive list. This would cover most AEC projects, and for those that it doesn’t
cover there are probably groups in buildingSMART working to cover more.

The Shared and Domain layer are the layers that AEC professionals would recognise. In fact, if one was to teach IFC, it may actually make sense to start off at these layers and work backwards. Otherwise, there’s a good chance people will get lost and turned off by the highly abstract nature.

Summary

What we’ve learned here is that the IFC schema is made up of a number of layers, ranging from highly generic to discipline specific. These layers are called the Resource, Core, Shared, and Domain. Between them, it’s possible to describe most things you’d ever want to describe in the AEC industry in a digital way.

This article first appeared on Tim Davies’s blog

Watch Emma Hooper’s NXT BLD 2022 talk on Information Models and the future of IFC. Register FREE

To learn more about IFC, read AEC’s Magazine’s IFC Special Report, produced in collaboration with buildingSMART United Kingdom & Ireland. See page 67 onwards.

The post Breaking down the IFC 4.3 schema appeared first on AEC Magazine.

Emma Hooper, Associate Director and Head of R&D at Bond Bryan Digital, provides a useful overview of the IFC data model specification

Over the course of a facility’s life, information is created and goes on a journey in which it is constantly exchanged by people using technology.

From the initial idea to construct a building to the deletion of this asset from a map following its demolition, a building creates a trail of information that follows it from cradle to grave.

This trail is invisible. Some call it a ‘golden thread’. I prefer to call it an ‘information layer’, which forms part of an information management ecosystem. But whatever you call it, this trail is currently fragmented and, quite frankly, a mess.

The purpose of information management is to view information as an asset in its own right. To get the full value from information, it must be rationalised and joined up – both processes entirely separate from software.

Two layers at work

The information management ecosystem is made up of two layers. First, there’s the management layer, which includes recurring cycles of information management activities, based on appointments. This is covered by ISO 19650.

Second, there’s the information layer, where the complexity of the different facets of information are broken down, structured, ordered and joined up, in order to provide a base data language for the activities in the management layer outlined above and for the technology to plug into.

The information layer is complex. There is no escaping that. Try describing one component in a facility: its type, performance, materials, location, name and all the other data related to it, plus the data about the data. And that’s just one component.

Now, multiply this to cover tens of thousands or millions of components and how they all connect to one another. The task is utterly mind-blowing in its complexity! So, the only way we can produce connected, machine-interpretable data is to use data models as part of the information layer.

What is a data model, anyway?

Essentially, a data model is a way of structuring and joining up data. It creates order and enables complex connections to be made. A data model is not a BIM model in the traditional sense, and it doesn’t have to contain geometry.

But we also need a standardised data model to provide a single data language throughout, otherwise we quickly encounter interoperability issues. Do we have something already? We do! It’s called Industry Foundation Classes, or IFC.

IFC is an off-the-shelf data model specification. It is managed by buildingSMART International (see buildingSMART article) and is an international standard, ISO 16739.

IFC provides a data framework for most of the parts of the AEC industry, allowing information to be connected. For example, a boiler might be connected to a pipe and associated with a particular system, along with the space and building in which it is located, a construction programme, commissioning certificates, performance properties, a cost plan, classification and so on. In fact, I could go on and on. What’s important is that there is nothing in the industry, besides IFC, that can accomplish so much in terms of connecting information across so many domains.

IFC is a digital representation of a built asset for a computer to understand.

Why do we need IFC?

Each proprietary software application has its own data model running in the background. These are typically packaged up in custom file formats for exchange purposes.

But these data models are bespoke and often poorly created, with the sole objective of serving the software. Therefore, when we exchange data between software packages, we run into interoperability issues, because these packages speak different languages. If software packages can read and write to a standard data model, they only have to create the mapping once, rather than a point-to-point solution for every permutation of software exchange.

It’s also not just delivery and the exchange of design information where IFC can play a part. Going back to the information management ecosystem, IFC is at the heart of the information layer as the standardised data model. Therefore, it can be used to provide data foundations to underpin ISO 19650 activities. IFC can be used to structure exchange information requirements, deliver them and assure the delivered data against the original requirements and store data during and after the project (see Gen Zero project article).

Because the data model is so big, it has to be broken down to exchange information. This is all done using filtered parts of the IFC schema called model view definitions. This approach is being redeveloped by buildingSMART to make it more flexible using information delivery specifications, or IDS.

The more we digitise, the more data models organisations will create. If we don’t have a standardised starting point for these, they will be structured in completely different ways and, as a result, sharing information between them will be as difficult as it is now between authoring software, just on a much bigger scale. Technology will not provide a magic solution!

IFC basics

The IFC standard is free and can be accessed via the buildingSMART website. There are currently two official versions:

1. IFC2x3 TC1 (IFC2x3) – this is aligned to ISO 16739:2005.
2. IFC4 ADD2 TC1 (IFC4) – this is aligned to ISO 16739-1:2018.

IFC2x3 is the predominant version used in the UK. However IFC4 implementation within software has recently accelerated and, together with the proposed release of IFC4.3 in 2022/2023, we need as an industry to start the transition to IFC 4.3 in the next year (see IFC 4.3 article).

Communication of the data model is carried out using a schema. This provides a data modelling language to represent a data model often in a graphical way, enabling a viewer to see what the data model contains and work out which parts are connected.

IFC can be visualised using several schemas. Currently, the principal one is EXPRESS-G, but the plan is to move to UML (unified modelling language) in IFC5.

On top of this, when transferring data from a data model, you need an exchange format to transport it. IFC typically uses the STEP physical format (SPF) which is text-based. (Because it has the ‘.ifc’ file extension, this has led to the misconception that IFC is just a file format.) Being text-based means that model files can be opened using a standard text editor such as Notepad.

Other exchange formats include XML and JSON and there are others in development. These include RDF/XML,Turtle and JSONLD, where the emphasis is less on exchanging files and more on exchanging the data.

IFC data model composition

In simple terms, IFC is made up of three parts: entities, attributes and relationships.

Entities are the main classes and, in the data model, act like nodes. In other words, it’s the entities that get connected. Most entities can be considered as objects – not just physicalbased objects such as walls and boilers, but also objects such as geometry, processes, properties, materials and so on. This means there is potential to perform cost schedules, resource planning and construction using IFC.

A particularly important entity is IfcBuildingElementProxy, which can be used where there is no appropriate entity. This acts like a template entity, identifying all the appropriate attributes and relationships. There is also the ability here to define the object further (see section below on predefined types).

Attributes define entities further by including basic data such as ‘name’, ‘description’ and ‘globalID’. Attributes also allow connections to be made to other entities by acting like hooks.

Relationships connect entities via attributes, and in the IFC schema, are objects themselves. It is the relationships that are key and will become even more important as we move into a more connected future.

Watch Emma Hooper’s NXT BLD 2022 talk on Information Models and the future of IFC. Register here

Predefined types, properties & external references

There are a few more terms with which users need to familiarise themselves.

For example, one important attribute is the predefined type. This allows an entity to be described further; for example, for IfcSanitaryTerminalType, predefined types include TOILETPAN, SINK, WASHHANDBASIN and so on. These are listed in capitals, just as they are on the predefined pick-list.

The USERDEFINED predefined type should be used only where there is no appropriate predefined type.

USERDEFINED still needs to be entered at the predefined type, but the entity can be defined further by using the ElementType or ObjectType attribute.

IFC also enables properties to be associated with objects. Before the association can take place, the property has to be assigned to a property set. A property set is a container of properties that have something in common; within the IFC schema, property sets are characterised using the ‘Pset_’ prefix.

Custom properties can also be added using custom property sets, but it is first important to check that the properties don’t already exist in industry dictionaries or lexicons.

Finally, let’s look at external references. IFC recognises that not all information will be captured within IFC models, so it also has the ability to associate externally referenced sources of information to IFC objects. The three external references are:

• Classification, which allows classification systems such as Uniclass to be associated to objects.
• Libraries, which allow data from external databases to be associated to objects (for example, product data manufacturers).
• Documents, which allow documents to be associated with objects (for example, a commissioning certificate can be associated with a boiler).

In summary, I would not claim that IFC is perfect – but as an industry, we need to team up and help to support, improve and evolve IFC across an ever-changing digital landscape. Those working in the digital information space need to know the basics. But the majority of people shouldn’t even know it’s there, because it operates seamlessly in the background. In fact, I’d go as far as to say that the more I understand IFC, the more I come to think of it as one of the greatest achievements in digital construction.

IFC’s benefits

• Free, off-the-shelf and ready to be used for almost any purpose, IFC brings big benefits. These include its ability to:
• Provide the data framework for information management activities • Enable repeatable processes and software configurations during delivery
• Deliver longevity and sustainability of data
• Side-step intellectual property issues and vendor lock-in
• Support more complex querying, via relationships, providing better insight for decision making
• Provide easier connection to external data sets via standardisation, for complex use cases like smart cities
• Accelerate advancements like machine learning

Click here for more information about buildingSmart UK & Ireland.

This article is part of AEC Magazine’s

IFC Special Report – Enabling interoperability in the AEC industry.

To read the other articles in this report click on the links below.

Industry convergence
From sustainability to new business models, and from wellness to emerging technologies, IFC can be a force for good, driving the AEC industry to new levels of achievement

Inside buildingSMART
What is buildingSMART and what can it offer industry practitioners?

IFC for Infrastructure
Perhaps the most significant update to the IFC standard is the inclusion of extensions for infrastructure entities in IFC 4.3

Native OpenBIM, and the rise of open source in AEC
OpenBIM can deliver on the promise of a digital world for the built environment where information and data are truly valued

IFC at Hinkley Point C
By Tim Davies, digital engineering manager, BYLOR JV – Hinkley Point C

Tackling the Gen Zero Project
The UK Department for Education’s Gen Zero project showcases how IFC can be used as the underlying data standard for a large, complex project, from start to finish

buildingSMART certification
By Phil Read, program lead at bSUKI and managing director, Man and Machine

The post IFC: what is it and why is it needed? appeared first on AEC Magazine.