DWGdirect and DRX Explained
In my previous post I briefly mentioned the DRX SDK and the DWGdirect SDK. There is a lot of confusion regarding these two and unfortunately the ODA is not doing a great job in explaining these two technologies. I am going to try.
The DWGdirect SDK is basically a clone of the ObjectARX SDK developed by Autodesk and which forms the basic framework of AutoCAD. The DWGdirect SDK has been used by the IntelliCAD Technology Consortium (ITC) to build IntelliCAD 7. It is also used by other ODA members to build CAD applications that they use in house or for their clients. The ODA prefers to call such applications DWGdirect hosted applications because they are built using the DWGdirect SDK as the framework.
I do not particularly like the fact that the ODA is calling their SDK “DWGdirect”, not because Autodesk wants to trademark “DWG”, but because the name seems to suggest that the DWGdirect SDK can be used to build software that stores it's data in DWG files (such as IntelliCAD), when in fact it can be used as a framework to build just about any CAD software. To give you an example, you can use the DWGdirect SDK to build software that reads and writes it's own file format. At SYCODE we are using the DWGdirect SDK to build the next version of TerrainCAD, our standalone terrain modelling software. TerrainCAD uses the OpenNURBS 3DM file format as it’s native file format and has nothing to do with DWG, apart from the fact that it can read and write DWG files among many others. The DWGdirect SDK offers the framework to store geometric data, show geometric objects in a drawing window, modify objects using grips, etc., none of which is related to DWG at all. So in my opinion the “DWG” in DWGdirect is misleading and I hope the ODA drops it for something more fitting. I look at the DWGdirect SDK as quite simply a framework to build a CAD application, not a tool to read and write DWG files. And quite frankly, I have a problem referring to TerrainCAD a DWGdirect hosted application. It just does not sound right.
The DWGdirect SDK is so powerful that any application built using it as a framework inherits a mechanism for third party developers to build custom applications (also called plug-ins) for it. That’s the main reason we are rewriting TerrainCAD using the DWGdirect SDK. So that third parties can extend the capabilities of TerrainCAD by means of plug-ins. These plug-ins are built using the DRX SDK, which is basically a subset of the DWGdirect SDK. Using the DRX SDK, programmers can develop plug-ins only, not entire applications. To get the DWGdirect SDK, you need to be a member of the ODA and pay them annual fees. But the DRX SDK is free and I love that fact. This means that when we build TerrainCAD using the DWGdirect SDK, anyone can use the free DRX SDK to build a plug-in for it. And the best part is that since IntelliCAD 7 is also built using the DWGdirect SDK, the same plug-in will work in IntelliCAD as well, or for that matter, any other DWGdirect hosted application like Bricscad.
I believe that this DWGdirect/DRX combination is a great Rapid Application Development tool for programmers who wish to develop and deploy powerful and robust software solutions quickly. At SYCODE we are looking at the DWGdirect SDK as a technology to build custom software solutions for our clients. Normally we design the custom solution as a plug-in to the client’s existing CAD system, or make the client buy another CAD system for which we can make a plug-in for. While this method works, it comes with the added headache of us having to upgrade our plug-in every time the client upgrades his CAD application, which is now an annual ritual. Moreover, we also have to ensure that our plug-in works with the service packs that the client installs from time to time. It’s too tedious and can sometimes get frustrating for the client as us as well. For example, we were able to port our SolidWorks 2007 plug-ins to 2008 only six months later, and that was a big problem for our clients. If we build our solution as a standalone application and make it scalable by adding features through plug-ins, life will be much easier. Moreover, our client can get a third party to further extend our solution. All they have to do is download the free DRX SDK and build a plug-in for our solution. The third party does not need to join the ODA, and neither does the client.
Like I said in my earlier post, the ODA is not just a “bunch of hackers”. They offer some real neat technologies and components. The sad part is that they are so consumed by Autodesk and the DWG file format that they seem to be forgetting the nice stuff that they have been developing over the years.
Take a look at their web site. This is what you see on the home page:
“The Open Design Alliance is a non-profit membership-based consortium of software companies, developers and users committed to promoting the open exchange of CAD data now and in the future. In addition to setting standards for CAD data formats, the ODA also focuses on the practical matter of developing software libraries of exceptional quality that enable ODA members to develop applications capable of reading and writing the popular DWG and DGN CAD file formats. ODA members use the following ODA software libraries to support their efforts of developing CAD solutions”
…and they go on and talk about DWGdirect and DGNdirect, about how these libraries can read and write DWG and DGN files. Absolutely nothing about anything I said above. No mention whatsoever about the DRX SDK. You need to click on a cryptic link called “Public Downloads” to even know that they offer something called the DRX SDK.
In my opinion, the ODA needs to take a serious look at itself. They have spent all this time, money and resources to develop a robust, powerful and scalable CAD platform and keep marketing it as a DWG read/write toolkit. Obviously, there is something seriously wrong here. Come to think of it, I cannot really blame people for considering the ODA as a “bunch of hackers” when they seem to believe it themselves.
ODA, look around. There is life beyond Autodesk and the DWG file format.
The DWGdirect SDK is basically a clone of the ObjectARX SDK developed by Autodesk and which forms the basic framework of AutoCAD. The DWGdirect SDK has been used by the IntelliCAD Technology Consortium (ITC) to build IntelliCAD 7. It is also used by other ODA members to build CAD applications that they use in house or for their clients. The ODA prefers to call such applications DWGdirect hosted applications because they are built using the DWGdirect SDK as the framework.
I do not particularly like the fact that the ODA is calling their SDK “DWGdirect”, not because Autodesk wants to trademark “DWG”, but because the name seems to suggest that the DWGdirect SDK can be used to build software that stores it's data in DWG files (such as IntelliCAD), when in fact it can be used as a framework to build just about any CAD software. To give you an example, you can use the DWGdirect SDK to build software that reads and writes it's own file format. At SYCODE we are using the DWGdirect SDK to build the next version of TerrainCAD, our standalone terrain modelling software. TerrainCAD uses the OpenNURBS 3DM file format as it’s native file format and has nothing to do with DWG, apart from the fact that it can read and write DWG files among many others. The DWGdirect SDK offers the framework to store geometric data, show geometric objects in a drawing window, modify objects using grips, etc., none of which is related to DWG at all. So in my opinion the “DWG” in DWGdirect is misleading and I hope the ODA drops it for something more fitting. I look at the DWGdirect SDK as quite simply a framework to build a CAD application, not a tool to read and write DWG files. And quite frankly, I have a problem referring to TerrainCAD a DWGdirect hosted application. It just does not sound right.
The DWGdirect SDK is so powerful that any application built using it as a framework inherits a mechanism for third party developers to build custom applications (also called plug-ins) for it. That’s the main reason we are rewriting TerrainCAD using the DWGdirect SDK. So that third parties can extend the capabilities of TerrainCAD by means of plug-ins. These plug-ins are built using the DRX SDK, which is basically a subset of the DWGdirect SDK. Using the DRX SDK, programmers can develop plug-ins only, not entire applications. To get the DWGdirect SDK, you need to be a member of the ODA and pay them annual fees. But the DRX SDK is free and I love that fact. This means that when we build TerrainCAD using the DWGdirect SDK, anyone can use the free DRX SDK to build a plug-in for it. And the best part is that since IntelliCAD 7 is also built using the DWGdirect SDK, the same plug-in will work in IntelliCAD as well, or for that matter, any other DWGdirect hosted application like Bricscad.
I believe that this DWGdirect/DRX combination is a great Rapid Application Development tool for programmers who wish to develop and deploy powerful and robust software solutions quickly. At SYCODE we are looking at the DWGdirect SDK as a technology to build custom software solutions for our clients. Normally we design the custom solution as a plug-in to the client’s existing CAD system, or make the client buy another CAD system for which we can make a plug-in for. While this method works, it comes with the added headache of us having to upgrade our plug-in every time the client upgrades his CAD application, which is now an annual ritual. Moreover, we also have to ensure that our plug-in works with the service packs that the client installs from time to time. It’s too tedious and can sometimes get frustrating for the client as us as well. For example, we were able to port our SolidWorks 2007 plug-ins to 2008 only six months later, and that was a big problem for our clients. If we build our solution as a standalone application and make it scalable by adding features through plug-ins, life will be much easier. Moreover, our client can get a third party to further extend our solution. All they have to do is download the free DRX SDK and build a plug-in for our solution. The third party does not need to join the ODA, and neither does the client.
Like I said in my earlier post, the ODA is not just a “bunch of hackers”. They offer some real neat technologies and components. The sad part is that they are so consumed by Autodesk and the DWG file format that they seem to be forgetting the nice stuff that they have been developing over the years.
Take a look at their web site. This is what you see on the home page:
“The Open Design Alliance is a non-profit membership-based consortium of software companies, developers and users committed to promoting the open exchange of CAD data now and in the future. In addition to setting standards for CAD data formats, the ODA also focuses on the practical matter of developing software libraries of exceptional quality that enable ODA members to develop applications capable of reading and writing the popular DWG and DGN CAD file formats. ODA members use the following ODA software libraries to support their efforts of developing CAD solutions”
…and they go on and talk about DWGdirect and DGNdirect, about how these libraries can read and write DWG and DGN files. Absolutely nothing about anything I said above. No mention whatsoever about the DRX SDK. You need to click on a cryptic link called “Public Downloads” to even know that they offer something called the DRX SDK.
In my opinion, the ODA needs to take a serious look at itself. They have spent all this time, money and resources to develop a robust, powerful and scalable CAD platform and keep marketing it as a DWG read/write toolkit. Obviously, there is something seriously wrong here. Come to think of it, I cannot really blame people for considering the ODA as a “bunch of hackers” when they seem to believe it themselves.
ODA, look around. There is life beyond Autodesk and the DWG file format.
8 Comments:
Excellent post, Deelip!
In the second paragraph you state that "The DWGdirect SDK is basically a clone of the ObjectARX SDK developed by Autodesk...". I think you meant to say that the *DRX SDK* is a clone of the ObjectARX SDK. I believe DWGdirect is roughly analogous to Autodesk's RealDWG.
By Owen Wengerd, At 8:24 AM, November 01, 2008
Owen, I do not have access to the RealDWG SDK, so the following is just my guess. The ObjectARX SDK has many types of classes for Database (AcDb), Geometry (AcGe), Graphics (AcGi), etc. You need all of these to create AutoCAD. But to read and write DWG/DXF files, you only need the AdDb classes and probably other classes linked to them. So I suspect that the RealDWG SDK is just a subset of the ObjectARX SDK, that contains the classes to hold DWG data.
Now as regards the Open Design side of things is concerned, I believe the DWGdirect SDK is a clone of the ObjectARX SDK. The folder structure of both are not exactly the same, but I can see similarity in functionalities. And I believe that the DRX SDK is the same as the DWGdirect SDK, minus the classes that allow creation of an application. The logic being that you need to become a member to make DWGdirect hosted applications.
Let me know if you get information that is contrary to the above.
By Deelip Menezes, At 10:56 AM, November 01, 2008
Deelip, you seem to be suggesting that DRX is analagous to ObjectDBX (a subset of ObjectARX). I'm only vaguely familiar with the DWGdirect libraries and the DRX SDK, so I'm not in a position to refute what you say. However, I think your implication that ObjectARX supports UI, therefore it is an "application platform" is not accurate. ObjectARX does not provide any UI implementation -- it only defines a public interface to the *AutoCAD* platform.
AcDbHostApplicationServices would be the "application platform" that is analagous to the IntelliCAD platform, and that is not part of the ObjectARX SDK.
The bottom line is that our conversation validates your point that there needs to be more work done to clear up this sort of confusion.
By Owen Wengerd, At 11:26 PM, November 03, 2008
So in what sense does the DWGDirect SDK compare to toolkits such as HOOPS? And do you still need a seperate modeling kernel such as ACID, ParaSolid or OpenCASCADE to actually develop a workable CAD application?
I assume that these kits (apart from OpenCASCADE) still not allow for the development of an Open Source CAD application.
By stefkeB, At 1:47 PM, November 04, 2008
Owen,
ObjectARX has classes that interface with AutoCAD's UI. To me an application framework is not the windows that make up the application. It is more the way the data is stored and accessed within the application and ObjectARX is exactly that. On the ODA side of things, the DWGdirect SDK is the equivalent of Autodesk's ObjectARX SDK. I agree that all this is so confusing, that sometimes I wonder whether I have got it right in the first place. I hope to research DWGdirect and DRX extensively in the upcoming months and will publish my finding/deductions here. I admit that I have a lot to learn and am nowhere close to being an authority on DWGdirect and DRX.
Stefan,
DWGdirect is an application framework that helps to tie a lot of other sub systems together. HOOPS is entirely related to graphics and rendering. ACIS, Parasolid deals with solid modeling. You are right, apart from OpenCASCADE, none of the SDK's you mentioned can be used as part of an OpenSource CAD application.
By Deelip Menezes, At 2:04 PM, November 04, 2008
Hi Deelip, I am working as AutoCAD Developer in a GIS Company and we are using AutocadMap for our daily production purpose. Now the company is insisting on using a more cost effective alternative to autocadmap. I have searched the Net for a good alternative but i am not able to find a single alternative to AutoCadMap. The one's which i found are just the alternatives to basic AutoCAD and not the AutoCadMap version.
Also for your information i would like to tell you that our primary functional usage from AutoCadMap is ObjectData , Topology , Inserting GeoReferenced Images.
I would be very Oblidged if you could help me in any way...
Thanks in Advance
Nilesh Valwaikar
nvalwaikar@hotmail.com
By nvalwaikar, At 8:16 PM, November 29, 2008
See https://www.intellicad.org/members/index.php
You may also want to post your question at www.intellicad.net and see if anyone out there responds
By Deelip Menezes, At 12:52 PM, December 01, 2008
Hi Deelip,
I am working as AutoCAD developer (Novice) . I make use of ObjectARX for processing AutoDCD (.dwg) files.
I want to know that whether it is possible to work with DWGDirect libraries under same project ?
By Anonymous, At 5:56 PM, December 01, 2009
Post a Comment
Subscribe to Post Comments [Atom]
<< Home