Continued from page 1
On the Open BIM Format IFC
Can you explain to me the background on the toolkit for IFC? What drove that? Is the issue that buildingSMART is really just not able to expand or drive the IFC mission to its fullest potential and the standard falls down at the software level…is that close to the truth?
Well, I think that buildingSMART has done a really good job of creating a standard but the assumption that was made when they started working in this area was that they would publish the IFC standard and people would do the implementations and everybody would work together. So, in theory, it is good. But in practice, the implementations seem that they just tend to fall short. And it doesn’t seem that there is any entity that has a vested interesting in building a top-quality IFC library.
And this is where the ODA steps in…?
It is different than what we normally do because with (.dwg) there is no specification—we had to go through and figure out everything about the (.dwg) format ourselves.
I think part of the problem is that it is not a money maker. Anybody can take the spec and write their own implementation of IFC. So a company coming in and looking at this with a profit motive—they are going to say “nobody is going to pay a lot of money for this when they can just write it themselves or they can use a free product.” But the problem is there are open libraries that are lacking in quality, consistency and too many implementations that cause problems during data exchange.
So when we develop our IFC solution we see the same pattern developing, where everybody adopts our implementation, and then you won’t see those types of incompatibilities with IFC either.
So we see an opportunity and the ODA is a non-profit. And as a non-profit, we are really focused on meeting the needs of our members and its never about making more money for us its about making a better set of tools that satisfy a real need in the industry.
So what is the primary shortcoming with IFC that the ODA will address?
I think the problem is that with the various implementations there are different ways to do things within the standard. And there are a lot of implementations that are not really supported by a professional development team. So it’s hard to get support, it hard to get things fixed. So there are a number of problems like that. It leads to frustration and compatibility problems and different vendors are using different solutions and then you have these subtle implementations which defeat the purpose of having one standard.
And so we eliminated that with (.dwg). People in the industry are using our technology. Outside of Autodesk, ours is the standard technology, everybody is using the same toolset. So we don’t have those types of compatibility problems. So when we develop our IFC solution we see the same pattern developing, where everybody adopts our implementation, and then you won’t see those types of incompatibilities with IFC either.
So will your Visualize SDK also support the IFC format so you can provide IFC models in a web-browser?
Well, our web viewer already works with Revit. And it will, even from the first release, be compatible with the IFC technology as well. There is a lot of demand for that.
I would imagine so because all of the web browser-based cloud tools in AEC—and there is an explosion of CDE (common data environment) applications—they view 2D drawings today but most, in the end, will want to support 3D viewing of BIM models.
Absolutely. That is probably one of our biggest requests in the last couple of years. This is coming from a lot of companies: they want to have a single viewer that works for all of the BIM related formats—(.dwg), Revit, IFC—they want to be able to load those formats into a common viewer, maybe do some markup editing, and maybe ODA can create a markup version output in some consistent format. So we are building exactly that technology.
The Grand Take on the Future of (.dwg)
So what is your grand take on the future of (.dwg)? It certainly seems like with the likes of Hexagon buying Bricsys, the continued traction made by Graebert and others, and with Autodesk’s expansion of One AutoCAD, an AutoCAD for every platform and device, (.dwg) doesn’t feel exactly like just legacy any longer. (.dwg) seems transformed.
Absolutely. When people talk about it as legacy technology—and that it is going away—that has been the discussion in some circle for quite a while now. But I don’t think that is going to happen for a couple of reasons.
One is that the (.dwg) technology itself is really good technology. Even though the initial (.dwg) format from Autodesk written back in the ’80s was simplistic by today’s standards, they did a really nice job in the ’90s in creating a solid architecture that is future-proof. It’s a format that is extensible, you can create custom objects that are extremely powerful on the user side, and people like it very much. It’s a well-liked and well-used CAD technology.
The industry is deciding that this is the standard technology and the way applications should talk to each other—that (.dwg) is the standard exchange mechanism.
But we are taking it much further. And now you see what some of our customers are doing. We built some of the missing pieces; there is a platform now on which to build (.dwg)-based applications. It is open to everyone and it is powerful. It has all the features you need. You mentioned Bricsys, for example, where they are showing you can do BIM and mechanical, and sheet metal, and all these other apps all within a (.dwg)-based environment. It is exactly what (.dwg) was always designed for—it exemplifies the whole basis for this technology.
It sure seems like a key moment in its history.
I think we have been at an inflection point for the past few years where for a period we have wondered if this technology is going to go by the wayside. But I don’t think that is going to happen. We have a lot of momentum now. It is almost like a resurgence in (.dwg) and it’s not just Bricsys but a lot of different companies, coming out with applications based on our technology.
The industry is deciding that this is the standard technology and the way applications should talk to each other—that (.dwg) is the standard exchange mechanism. I don’t think the technology is going away if anything we are going to see some nice growth in this area in the years ahead.
Reader Comments
Comments for this story are closed