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