10 minute read time.
This article looks at 3D BIM objects and what went wrongBack in our second article we briefly touched on how the BIM object development exercise became a ‘very expensive failure’ for many manufacturers. We thought we’d look in more detail into why geometry is not the holy grail of BIM, why information management is so much more than geometry, and why we will be recommending to readers of the Plain Language Guide for manufacturers that they don’t think about 3D BIM objects but think about owning and controlling their data.

 

A misplaced devotion to 3D


A BIM object is a 3D digital representation of a construction product, material or system, with associated data attached.


If you’ve attended any BIM events over the last five years or so, you’ll often have heard the lament that “BIM is not 3D”. Commentators are concerned that people have mistakenly believed that BIM equates to a 3D model, and that is all that it is.


However, those who have this misconception cannot be blamed for feeling this way. The obsession with 3D objects as “the be-all and end-all of BIM” is understandable. It has its roots in the poor communication of what BIM is.


The misconception that BIM is 3D has affected people across the supply chain, but Manufacturers have been especially affected. By having BIM objects, manufacturers believed that they were ‘BIM ready’.


They were not. This is what happened.

 

Aggressive Selling


The misconception that BIM was 3D was fueled by a rapid and aggressively targeted campaign by several BIM library businesses (who make and host 3D BIM objects) to tell manufacturers that having 3D BIM objects or even multiple objects representing various systems and variations of use of their products, was essential to operating in the new construction world.


Manufacturers were told that whereas before being ‘in the spec’ was the thing, now you had to be ‘in the model’ and ‘BIM compliant’ and that meant 3D BIM objects.

 

Marketing not Data Management


Many manufacturers saw BIM as a marketing opportunity, not a data challenge. They diverted part of their marketing budgets, not their data management budgets, to pay for it. 3D BIM objects have a tangible attraction in themselves, and many were produced for their aesthetic appearance rather than for the data they held.


This resulted in huge, overly intricate 3D BIM Objects being created. These objects’ size and geometric complexity was totally unnecessary and could even cause designers’ models to crash. These objects are not created to hold necessary data, but to market the concept to architects who are perceived as attracted to 3D renders.

bf8a16bbee7a84e63d0e6584dd86beb0-huge-bimobject_1_valve.png
Example of an overly complex rendering of a small component as a BIM Object


Beautifully rendered 3D representations of products are appropriate for catalogues and architectural renders, but not for models of complex buildings in BIM. Models in BIM are information models, not architectural renders, and objects with large wasteful file sizes just make them heavy and unstable. BIM software tools like Revit were not developed to produce 3D renders; they contain more than geometric data and there are other, better tools for rendering.

0bb90f45ec6600ee2f2d7f2cb5baaddf-huge-bimobject_2_dyson.png
Some objects have even been produced with shadow data

eca9d17c816ebc2646c64583c5e728b3-huge-bimobject_4_lightswitch_keithwilkinson.png
Example of an overly detailed small component provided for use in BIM multiple times (source)
0f0adf3ee912ba1b2ef8f283d3e47de2-huge-bimobject_4_lansockets_paulalexanderbrown.png

 

Paying for Multiple Formats and Classifications which are not Comparable


Manufacturers believed that they had to produce their objects in several “formats” – Revit, ArchiCAD and IFC were the common ones, even though IFC is not a format or a software application, it is a standard for data exchange*.


They paid third party providers to produce these different versions of their objects, each with associated product attribute data attached to geometry in the appropriate format.


Larger manufacturers who used several different third parties (not always by their own choice) for their BIM object providers discovered that when comparing objects from different providers, the data in them was organised in a different way with the same attributes given different names so specifiers could not even compare identical products. Some of these providers were mandated by contractors as a condition of a commercial relationship.

99f1e8eae9e824589768d867549f7be3-huge-bimobject_3_wienerberger.png
The same attributes given different names


Part of the reason for the mistakes outlined above was that the standards EN ISO 23386 and 23387 were not there to create a single digital data language. However, the result was that to fill that gap, manufacturers were paying for various complex versions of one product at huge expense.

 

Being ‘in the Model’ isn’t Being ‘in the Spec’


So how did this situation affect designers? Did it mean that once you had made your objects, you were ‘in the spec’? No, it didn’t.


With the focus on 3D objects rather than data, the emphasis was primarily on geometry and coordination. Designers were encouraged to seek out 3D objects from a variety of third-party providers.


The problem for a designer is that they may be making a model early in the process, before detailed product decisions are made. A designer may therefore use products (and their BIM objects) that they have used before, but only as a placeholder for later replacement. The requirement for placeholders led to the emergence of ‘generic’ (non-specific to a manufacturer) BIM objects.


The specification for a project often develops outside the 3D model, where designers can begin with performance specifications rather than specific chosen products. Depending on procurement processes, the choice of actual products may happen very late in the process, and rather than being fixed in the model, is still subject to change.


Meanwhile the model contains a mixture of proprietary and generic objects that may not be aligned with the emerging specification, and with some adding considerably to file size.


More importantly the objects have embedded in them erroneous information that may not align with the defined project requirements, or the emerging specification. Updating that information is time consuming and difficult.


This dilemma was set out in the 2018 report, A Fresh Way Forward for Product Data: State of the Nation, in chapters 3 and 5. We argued that


“Embedding data in objects means updating data is difficult once it is placed in a model, particularly with so many sources of objects on the market. For large projects objects may exist in a model for several years and products may have changed through that timescale, making the information unreliable.”




 


 

An Expensive Mistake we can Learn From


A great deal of money has been wasted producing 3D objects that are unnecessary, overly complex and don't even go in the model.


This is embarrassing for the people who were miss-sold BIM objects, and it is difficult to admit such a mistake. But we mustn’t blame the actors in this game – they were misinformed or misunderstood. Perhaps we all were.


There’s a reason why the rear-view mirror is so small and the windscreen is so big. Where we are heading is so much more important than what we need to leave behind.


The landscape is changing, and it is important that manufacturers know that they don’t need to make 3D objects to provide for a transition to BIM.


The challenge we face is not unique, it is mirrored in other industries. The videotape ‘Format War’ between BETAmax and VHS video cassette formats in the 1970s and 80s is an example. BETAmax was considered a higher quality format, but VHS was cheaper, simpler and did the job the market required. It would be great to have a completely integrated 3D modelled BIM world, but what we have is a series of ‘Little BIMs’ for different purposes, with 3D when it is required, and not always.


Many products don’t even have a reason for proprietary geometry. For example, with insulation, plasterboard or paint, the difference is in the performance attributes, not in the geometry.


The emphasis on 3D modelling has neglected the real value – the value of data itself.

 

Geometry is only a subset of Data


Designers have always incorporated geometry into their design processes. Precise geometry allows for us to design in 3D and locate objects in a coordinated way. It can help with clash detection for example – that is to identify when objects in a model are not coordinated spatially.


A 3D model also has potential, if properly done, to take its place after construction, to serve as a 3D representation of the built asset. Geometry also has its place for the geo-location of objects such as hidden services, enabling a maintenance engineer to identify where services run behind a finished surface (which could be a plasterboard wall, or a tarmac road). However, these scenarios can only work if the model is an actual representation of the asset and not a superseded version. Even then, it doesn’t have to be ‘complete’ with all the screws and fasteners, to have a purpose. It can be a partial picture, as long as it is an accurate one.


Geometry is only part of the value of information management, as geometrical data is only a small part of data. 3D objects are still relevant but not always; objects are optional, but information is not.

 

 

Focus on Information not Geometry


The information required to construct a project, and the information required to operate an asset, is collected by the contractor in order to comply with the clients’ requirements as set out in their Exchange Information Requirements (in accordance with ISO 19650). That information can then be used by clients in their asset management and CAFM systems to manage their buildings. The contractor has to collate this information as it is installed, and they cannot rely on the BIM model to do this.


It is no surprise therefore, that back in 2017 Nick Tune reported that contractors like Skanska had publicly stated that they do not want BIM objects from manufacturers, they just want the product data.


By structuring their product data and making it available in a secure, verified and interoperable way, manufacturers are able to meet the needs of designers, contractors and their clients and asset managers, without the need to produce 3D Objects with data that is ultimately inaccurate and unreliable.


The power lies in the data, not in the geometry.

 

 

Share Your Views


We are sharing a number of articles investigating how construction product manufacturers can solve the problem of product data management. This is part of the process for developing a Plain Language Guide to Product Data, written specifically for the CEOs of manufacturing companies. If you’d like to know more about this project, please subscribe to this blog using the link below and we’ll notify you as new items are published.


In the meantime, we want to encourage as much debate about the challenges as possible. 
  1. Please comment below with your views and share this article with the #ManufacturersPLG hashtag.





We look forward to hearing your views.

*IFC is a standardized, digital description of the built asset industry. It is an open, international standard (ISO 16739-1:2018) and promotes vendor-neutral, or agnostic, and usable capabilities across a wide range of hardware devices, software platforms, and interfaces for many different use cases. Source



 
  • I have yet so how people use the model from an operational perspective. To me, the "BIM" bit of the model just seems to be a way to generate a COBIE drop which is then imported into a CAFM software package. Being an electrical building services engineer my experience of most CAFM software packages just record and monitor the electrical information at a system level as that's how it maintained for compliance purposes.

    I think like TonyM points out, there is a need for change but unfortunately, the unaware design houses are been driven by the software distributor's BIM specialists, and the clients being sold something that they believe they should have to stay at the cutting edge of construction methods. Don't get me wrong it has a place in the right environment but generally, we are just using 3D cad.
     
  • Former Community Member
    Former Community Member
    ",sans-serif">There is no point in the Construction industry trying to treat the admittedly very painful symptoms described in this article. To cure the illness, a radical change - better late than never - is required:

    ",sans-serif">Release "BIM" from the surly bonds of "Building Information Modeling", and let it fly as the all-encompassing "Building Information Management".

    ",sans-serif">In this new context (which should have been the original one), it is immediately clear that the 3D model, which is important in itself for many reasons, is only a part of "the big picture": the Common Data Environment (CDE). Not only that, but the more recently added 4th (Time) and 5th (Cost) dimensions of BIM immediately fall into place, with more to follow.

    ",sans-serif">As for the expensive mess of 3D BIM objects, this must be attacked on several fronts, because it is a direct consequence of the widespread failure of the industry to understand the full extent of the capabilities of CAD software packages.

    ",sans-serif">Common format for BIM objects

    ",sans-serif">The first nettle to be grasped is understanding that a CAD drawing is nothing more than the visual representation of the information about each entity (line, circle curve...) it contains as an individual record in a "free" (but constrained)-format database file.
    ",sans-serif">The software provides the ability to group such entries together, to build named objects (aka blocks). Furthermore, copies of these objects can be saved in separate libraries, for future reuse in other drawings. This is how construction product manufacturers' block libraries came into being.
    ",sans-serif">Unfortunately, like a cancer they have grown unchecked, because of a failure to understand that the software has always contained the tools to limit their growth; and they have metastasized as a direct consequence of the failure of the industry to agree on a common format for storage of the basic data describing an object, which must be same for all users.

    ",sans-serif">At this point, a short digression is appropriate:
    ",sans-serif">CAD software vendors, keen to lock customers into the "ecosystems" built around their proprietary drawing formats, extol the advantages of their products by pointing out such things as the "friendliness" of their user interface (UI) and the quality of their rendering "engine". It is time to point out that these are secondary, not basic features - and take a look back at the 1980s.
    ",sans-serif">Back then, as the power and speed of PCs and the capacity of their memory began to grow rapidly, the concept of WYSIWYG - "What You See Is What You Get" - emerged, notably in relation to the spreadsheet package Lotus 123, which linked a WYSIWYG file containing the "pretty" display information to the original data file, which remained accessible to older software packages.

    ",sans-serif">In today's context, the important point is that the user interface and rendering information are both independent of the basic object information, which can therefore easily be placed in a data file of a common format, at a single stroke slashing the size of manufacturers' product object libraries and avoiding all the many disadvantages of continual inter-format translation.

    ",sans-serif">Visibility control

    ",sans-serif">At an early stage, CAD software vendors found that, often, displaying all the information contained in a drawing was a definite hindrance. So, the concept of layers, the display of which could be switched on or off at will, was created. Subsequently, when 3D drawing became common, the creation of algorithms for the removal of hidden lines in a view became a priority.
    ",sans-serif">It was also recognized that, for many often discipline/trade-related purposes, different combinations of visible and invisible layers were needed, so the ability to name these different views was provided. It is this existing facility which should be used in manufacturers' product data libraries to respond to a named Purpose View (PV) request by delivering a common format 3D BIM object containing the appropriate selection subset of features and a corresponding subset of the common format information held in the Product Data Template (PDT). At the user end, the desired view mode would be set by selection from a list in a pop-up dialog box appearing on opening the BIM project model.

    ",sans-serif">"Skin" objects

    ",sans-serif">As manufacturers' product objects often have unwieldy, detailed filenames, to simplify design and avoid mistakes due to "typos", it is helpful to create "skin" objects with simple names to enclose them. This procedure is especially useful when there is need for a Contractor to offer different options when tendering for a project or when, in O&M, it is found that the approved item is no longer available, so an alternate must be used. All that is needed is to change the link inside the skin.
    ",sans-serif">For proper implementation of skinning, it is essential that the skin object and all the alternate objects which may be put within it have the same insertion (aka reference) point - for example, bottom left front corner, 3-axis orientation, and units/scale. This must therefore be specified in the PDT.
    ",sans-serif">As the dimensions and fixings of an item of building equipment - for example, a Fan-Coil Unit (FCU) - produced by different manufacturers are likely to vary, in the O&M context the use of skin objects can permit trial replacement in the digital twin (DT), to determine the impact of a proposed change and plan the logistics for it.
    ",sans-serif">The PV mode, set by a viewer when opening the BIM project model, would be passed as a parameter whenever a link from a "skin" object in the project model to the corresponding "real" BIM object in a manufacturer's product library was invoked, minimizing the amount of data to be transferred from the external source to generate and refresh the model view. 

    ",sans-serif">Virtual objects

    ",sans-serif">The spread of the Internet has meant that design work on large projects is now often shared among several AECs scattered in all corners of the world, as also may be the project construction sites and the manufacturers of products used on them. Furthermore, the increased traffic capacity of modern optical fiber data cables has facilitated the creation of federated project BIM models, rather than having a physically single CDE. However, while 3D BIM project model objects can already be directly linked - admittedly, sometimes not very efficiently - to the associated project data, keeping track of construction progress and the associated costs on scattered sites presently requires delving into separate, dedicated software packages.
    ",sans-serif">A solution to this is to place within the project model, and directly associated with the "real" BIM objects to which they relate, normally invisible "virtual" task progress, cost, and status objects - perhaps as 2D labels set parallel to and slightly above a surface, so as to remain visible above rendering. If continually updated by means of Application Program Interface (API) links from the corresponding project files in the respective software packages, these critical project data could be checked directly by viewing the model in "Virtual Objects ON" mode, without the need to look elsewhere for the information.

    ",sans-serif">Aggregation software

    ",sans-serif">There now exists a plethora of software packages which offer to create a "one-stop shop" at which all the data related to a project - not just that related to CAD and products - can be viewed (in an "open" format) and manipulated (if the viewer is permitted) using any web-connected device.
    ",sans-serif">One of the main purposes of such packages was to overcome the problem of BIM model data held in multiple incompatible formats, by translating it all into the native format of the aggregator. However, that process only adds to the energy demand. Hopefully, following the comments in this response would make that largely unnecessary; but it would still leave the huge scope for making all the other project-related data readily accessible.
     
  • Former Community Member
    Former Community Member
    Just printed out, for me to review at leisure. I expect to have a field day!