INSIDER: A (.dwg) Renaissance—Neil Petersen of the ODA Explains Why

SO YOU THOUGHT THE DWG file format was legacy. Think again. It turns out the file format famous due to Autodesk’s AutoCAD® is on a new rise in popularity and innovation. And it’s coming from multiple players but the biggest and most important player is the Open Design Alliance (ODA).

Several weeks ago I had the pleasure of speaking with ODA president, Neil Petersen, about the present and future state of the Open Design Alliance and its work with (.dwg) and other CAD industry standards including IFC (Industry Foundation Classes). The conversation left me somewhat stunned. The non-profit CAD industry consortium is on a roll, with some remarkable new developments that are going to really shake up the CAD industry in the next few years.

It will definitely be to the benefit of the industry’s millions of users. Without further ado, let’s jump right to it and hear what Petersen had to say.

The Interview

ODA’s (.dwg) Technology and History

(Anthony Frausto-Robledo) Neil, some readers may not be familiar with the ODA and its work in creating industry open (.dwg) technology to enable interoperability with AutoCAD’s popular CAD program and its CAD file format. Can you explain some history to catch us up on that?

(Neil Petersen, ODA). Sure. We have been working on (.dwg) since 1998 and (.dwg) is really the reason why we were founded. In the early years, the main distinguishing factor, as distinct from (.dwg) support from Autodesk, was that our product was built as a cross-platform solution from the ground up. We built it from day one to run on Linux, Mac, and different flavors of Unix—pretty much every platform besides Windows.

So back in the early 2,000’s, there was a lot of new development going on [at Autodesk], so we were playing catch up for a long time, maybe ten years, just trying to get up to the same state of where Autodesk was with the technology.

How fundamentally compatible is the ODA’s (.dwg) technology compared to Autodesk?

Our technology is not binary compatible with the Autodesk technology but it has all the same functionality at the highest level. You can create your own custom classes and create your own applications and that sort of thing.

We developed that through the early aughts and probably around 2006 or 2007 we started to see companies like Bricsys, Graebert and ITC and other taking that technology up and building entire CAD systems on top of it.

So what is in the fact that it is not binary compatible? How does that affect the back and forth of working between ODA-based (.dwg) files and native AutoCAD files?

So when we load a (.dwg) file and save it back out we don’t lose any data. The file itself is going to be a perfect 100 percent (.dwg) file. What is different is that the API (application programming interface) that our customers are using to access that (.dwg) data is slightly different than the API that Autodesk offers. The API is the thing that is not binary compatible. If you are talking about an ObjectARX® (AutoCAD Runtime eXtension) application, you can’t just use that with our technology, it would have to be rewritten slightly because our API is different.

So that is where the support for custom AutoCAD tools, written as ObjectARX applications, begin to break down a bit?

So what some of our customers have done, like Bricsys, is they have gone in and created a layer between our technology and have created a set of wrappers that sort of emulate ObjectARX. In the case of Bricsys, they have their BRX SDK product that is source-code compatible with ARX 2007 or higher, so an ARX developer can come in and compile their program and use it without any changes for the most part.

Future (.dwg) Technologies

I saw several years ago in Berlin that the ODA had advanced its work with (.dwg) enough where you could have multiple users working together in the same (.dwg) file. What is the state of that technology?

That technology has been under development for several years. So to just walk backward a bit…back in 2010 we essentially were compatible with Autodesk. Then in 2015, we noticed that the pace of (.dwg) development was slowing down; we got to the point where we offered all of the same functionality that they had and were looking for ways to improve and extend the technology.

 

 

 

 

So one area was a version control system for (.dwg). One of the problems with (.dwg) is that if one of your engineers was working on a drawing and years later you want to go back to see what the changes were, you have no way to really do that. When looking at the software world we have tools that keep track of those types of things. You can go back and see every change that has been made, which is written in say C++ for example, and you can see who made that change and you can look at different versions or states of the file to see exactly what those changes were.

In the CAD world, there hasn’t been an easy way to do that with (.dwg). If you wanted to save the history of your work, you would have to save a full copy of your (.dwg) file over and over again. At some point, if you have a hundred thousand changes, if you have a 100 MB file, it becomes totally impractical to do that.

So what we have developed is a version control system for (.dwg) that essentially lets you save the entire history of a (.dwg) in a single file.

In a new file or the same (.dwg) file?

A new file. So think of changes like a circle or a line; we write those changes, the delta, in a compact form to a single file. And then, as a user, you can go back and look at an entire list of changes that have been made to that drawing, and you can do things like a visual difference, you can do a “visual diff” and look at the differences visually from like a week ago or see a text description of what has changed, and more importantly, you can create what we would call a branch in that drawing file.

A user can check out the file and then create a branch and start making changes. And at the same time, a second user can begin making changes to that drawing, making their own branch, working simultaneously, then when you want to resolve things with both drawings you actually make a “commit”— you are saying you re finished with your work and pushing those changes back to the main parts of the file.

And what about conflicts? Who touches what?

We have a conflict resolution system because it is possible that two users can modify the same objects. We would detect that situation and let one of the users who is changing an identical object and inform them they are changing work that was just changed by someone else,  and ask the user “how do you want to deal with it?” You would have a way to resolve that type of conflict.

In the software world that is a normal way of working.

So we are setting up the same process and you can have the same way of working with (.dwg) files. And so, if you want to save your version [control] history you can do that within a single file. We have a new file format called (.dsf)—drawing stream format.

And is that in your SDK code libraries now? 

That is in our library now; we are in the late beta stage. We announced it at our conference in Prague, earlier this year. And we have been working with some of our member companies to get it integrated into their solutions.

So what are some of the things that your ODA members are asking for in the evolution of (.dwg)?

In recent years we have been getting a lot of requests for complementary technologies. The new PDF technology is one area, where customers want to take (.dwg) data and publish that data in 2D or 3D PDF format.

We are also getting a lot of demand for working with (.dwg) files in a web browser. So we have developed a new Visualize SDK; it’s a toolkit that provides fast and professional visualization of (.dwg)—actually all of the other supported formats—in a desktop application or a web-based component. So as a developer you can easily build a web viewer for (.dwg) and the other formats—not just viewing but also support for basic markup editing on (.dwg) data.

The other area where we have seen a lot of demand is we have people who work with (.dwg) technologies sometimes for decades and they want to pull in other file formats. So we have recently added support for Revit files because we have customers who want to pull in a Revit model into a (.dwg) environment.

To clarify, you mean import in a Revit model into a (.dwg) CAD application to get at its geometry?

Yes. And we get these same requests for all of the other formats we support also. IFC support is not even finished yet and people are asking for the same thing—can I pull in an IFC model into my application?

So we are building what we are calling an “exchange framework” that makes it easy to pull in any other format we support. So as an ODA member developer, it will be easy to pull that data in and work with it in your (.dwg)-based application, to make it convenient for (.dwg) users.

I have read about the new IFC (industry foundation classes) support. Is that built into the exchange framework as well?

Yes, it will be. When we finish the IFC support, which will probably be later in 2019 to get to the initial version, you will be able to take an IFC file and work with the geometry in a (.dwg)-based application.

next page: What the ODA is doing to transform the reputation of the IFC format

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 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.

 

 

 

 

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.