The glTF file format is a new 3D model viewing format that has gained endorsements from such tech giants as Microsoft, Google, and Facebook. It already has a vast array of open tools available and is supported by many pieces of software.
glTF is described as the JPEG of 3D models.
glTF is taking off in the visual effects world, but why should we in the construction industry care about it?
The last decade has seen a revolution in the amount of 3D modelling that takes place in the construction industry. We are producing vast quantities of 3D models with high levels of detail and the scale and complexity is only going to increase in the future.
And seeing as no one knows 3D models better than the visual effects industry, if they’re getting excited about glTF, it’s most likely well worth us looking at it too.
In this mini series I’ll be looking at:
- Part 1: The current state of construction and the cloud
- Part 2: What glTF is and why it is important
- Part 3: How glTF could be applied to construction
Groundwork
Before we dive into the glTF format and exactly how it’ll be useful for construction, we need to take a look the current state of 3D modelling formats in the cloud and on mobile.
One of the biggest complaints from the construction industry around the use of 3D models has simply been the difficulty in getting models from one software package to another software package.
I’m not going to suggest that this problem is completely solved but the clear winning solution to this is the wide spread adoption of the IFC file format.
IFC ❤️
The last thing I’d want to do is to introduce more confusion into the construction industry by saying that we should be looking at something new instead of IFC, so I’ll categorically state that IFC is the best available format for exchanging construction and facilities management project information.
One of IFC’s biggest strengths is that it is incredibly versatile. It can represent all sorts of data in a variety of ways. IFC can handle extrusions, sweeps, arrays, meshes, boolean geometry, and more. But unfortunately in many ways this can be it’s weakness too.
In order to support all of these data and geometry types and perform accurately all the required geometry calculations that take into account all the possible variations, very powerful and comprehensive software is needed. Something as simple as viewing the 3D IFC model of a building suddenly becomes very difficult and potentially time consuming.
Despite us in the construction industry generating so many 3D models, the vast majority have little understanding of the fundementals of 3D geometry processing. Almost all the complexity is hidden from us by the software we use. This is fine on a day-to-day basis but means we often struggle to grasp why our 3D models sometimes behave the way they do and, more crucially, how to solve problems that may arise.
So to properly understand the context of how glTF will help us I’ll need to let you into a couple of secrets.
Secret 1: Everything is triangles
You may think you have some lovely sweeping architectural curves on your building model, your structural columns may look perfectly round, and your pipes may have a shimmering circular look, but on a computer they’re all just made up of lots and lots of 2D triangles arranged in 3D space into a ‘mesh’ to give the impression of smoothness.
Why triangles? Its because the graphics cards in your PC can only ever render triangles. And this is because a triangle is the only shape that is guaranteed to be correct in 3D. Just think about it… any three points in 3D space will always make a geometrically correct triangle, but four points or more may not make a rectangle or other valid shape. This restriction leads to optimisation so that triangles can be lightning fast to render.
Most of the time, software tools hide all the complexity away from you, but even when you are modelling they are converting everything to a series of triangles underneath the hood of your editor.
Remember I said about all the calculations IFC software has to do above? That is mainly the process of converting the shapes described in an IFC file to a series of triangles that can be displayed and rendered on your device’s graphics card.
On desktop hardware, the speed of calculation and compatibility isn’t too much of a problem, there are lots of IFC tools out there that can open and display 3D models very quickly. But what about comparatively low powered mobile and even IoT devices? The processing and memory constraints can make programming a piece software that can efficiently load complex IFC models and do all the calculations required very difficult and slow to perform.
The likes of Autodesk Forge, Trimble Connect, Bentley Navigator, Builderstorm, BIMStream, and many more are all actually achieving efficient mobile model viewing, so it must be possible to do, but how do they do it?
With the increasing usage of cloud storage systems like these, its extra important to understand just what vendors are doing to our models when we’re uploading them to their servers. So let’s look at secret number 2.
Secret 2: Your cloud viewer is not showing you the model you uploaded
The solution that almost all vendors implement is that when you first upload your file to their cloud they do all the geometry processing once and save the result as a set of pre-calculated triangles. When you request to view the model what they actually send to you is not the model you uploaded, but the pre-calculated geometry for almost immediate display and rendering. This significantly saves on processing on your device and is a good example of the advantages of the cloud.
An important point to remember is that each cloud each vendor actually has a slightly different way of transmitting their preprocessed models and they all use different file formats.
A major selling point of cloud vendors is often that you can view many different file formats. This isn’t strictly true, in fact their viewers can only view their own format.
And in the darkness bind them…
Forge uses SVF, Trimble uses BQL, and Bentley uses iModels, which are all proprietary, closed, and undocumented formats. This is very concerning for the industry because it has a created a 1-to-1 binding relationship between cloud storage and cloud model viewers.
If I upload a model to Autodesk, the only way I can view it is with the Autodesk Viewer. If I upload it to Trimble, I have to use Trimble’s viewer. If I upload it to Bentley, I have to use Bentley’s viewer.
Vendors try hard to make this process as transparent as possible so you don’t realise, but it causes a big headache for procurement and decision making. Why do we have to purchase both cloud storage and viewing capability at the same time? Imagine if to use Navisworks we had to buy Western Digital hard drives, or to use BIM Collab Zoom we needed Samsung SSDs. It would seem ridiculous to purchase both storage and model viewing software at the same time.
One more scenario, what if the main contractor is using ASite (which does include a model viewer) primarily for document management but their subcontractor likes to use the Trimble Connect mobile viewer in the field? They use different formats so they’re out of luck. We might end up having to purchase both solutions when we may only want a bit of each and awkwardly synchronise files across, which will obviously lead to higher costs and risks of error.
The current state of cloud construction isn’t improving integration, if anything it’s increasing siloed behavior even further. We are struggling to use the web to its full capabilities by failing to demand that services should be able to connect together.
Locked In
With data storage and model viewing being two major pillars in the digitisation of construction, the binding together of these two separate functions is a big problem.
Many of us lived through the dark ages of when DWG ruled the industry when a single file format locked thousands of us into a single piece of software and stifled innovation for years. The next stage creates the possibility of not just locking businesses into a file format and software, but entire ecosystems, storage, and platforms.
There is a need for a way to easily share 3D models across platforms and over the web in a way that allows other applications to view them in a lightweight, simple, and consistent manner.
Summary
To summarise Part 1, we’ve discussed how:
- IFC is a great format, but is rather heavyweight for just model viewing tasks.
- 3D models are always rendered as triangles.
- Cloud vendors turn your 3D models into their own secret format.
- That format can only be viewed in each vendor’s own viewers.
- Therefore cloud storage and cloud viewers are bound together.
- Great potential for extreme vendor lock in.
How do we solve this problem? This is where glTF comes in!
We’ll see how it helps in Part 2…
Constructing Data 
One thought on “glTF and Construction – Part 1: Secrets of the Cloud”