The Evolution of CAD
Chapter Two:
The Trouble with Proxies
Written By Martyn Day
In chapter one we covered the basics of object modelling, now it’s time to take a closer look at the technical issues that face the early adopters of this software. Martyn Day has spent the summer talking with the leading industry technologists to identify exactly what level of interoperability and data portability these initial releases will offer. This chapter looks at the ‘Proxy’ issue where data and intelligence get separated.
The argument for or against object-based modelling is really not the purpose of this article. For me, the main issue appears to be the industry’s approach to implementing the technology while standards can at best be described as embryonic. Evolution versus revolution is perhaps a fitting description for the arguments divulged here, and I’ll especially concentrate on the problems which early adopters will face and will, in turn, hand on to those who they share files with.
While the idea for an article on this new object technology has been in the back of my mind for a year or so now, one recent event lead to the writing of this article. I asked our regular contributor, Andrew Bichard to review the ‘Express Tools’ – a suite of productivity tools which you can down load from Autodesk’s Web site. On investigating one of these additional AutoCAD commands, Andrew discovered something untoward. One of the features enabled AutoCAD users to ‘XREF’ text from a word-processor document into an AutoCAD drawing. This was a very neat and fast way of entering text. However, if you gave that DWG to someone who didn’t have the Express Tools, AutoCAD would warn you that it was loading a ‘proxy’ and would place a big ‘X’ where the text should have appeared. If you listed the crossed out box it is described as a proxy object and advises you to go to the Autodesk Web site where, you would have to purchase the tool to see the text!
This differs from adding other AutoCAD applications developed in LISP or ADS (AutoCAD Development System) as each of these methods just creates standard AutoCAD components – lines, circles and arcs, which every AutoCAD can read. By defining the new entity as an object, every AutoCAD that loads a drawing containing an ObjectARX definition (like a wall, door, or a special entity) requires the application to be running to understand how that saved data works. This, for me, is a fundamental change in the way applications work within AutoCAD. If the use of ObjectARX applications flourishes then the probability of loading a proxy in vanilla AutoCAD will increase accordingly.
So, the introduction of custom objects could seriously interfere with DWG compatibility from AutoCAD to AutoCAD, let alone AutoCAD to some other design software. Time for some serious investigation, and probably another cup of coffee.
Object reality
Just after AutoCAD R13 was launched, the term ‘zombie’ soon became a point of discussion in the CAD world. Because AutoCAD R13 saved only the parameter information of an object to the DWG file, without the definition of what AutoCAD was supposed to do with it (the ‘intelligence’), a vanilla copy of AutoCAD that didn’t have the same add-on couldn’t see or do anything with that object. This was pretty bad as AutoCAD did not display any geometry at all – you wouldn’t have even known it was there! So, in short, one AutoCAD user could, by using an ObjectARX add-on, create a DWG model, which another AutoCAD user couldn’t even view, let alone edit. The nickname ‘zombie’ was really quite apt, data was capable of existing in the DWG file but without any intelligence.
As many developers had not embraced R13 or Autodesk’s new object development tools (ObjectARX), this wasn’t a very big deal. So the likelihood for receiving a zombie and its associated problems were very slim indeed. Autodesk recognised that this was a future problem and so enabled AutoCAD to alert the user that a zombie was in a DWG file being loaded. Autodesk also changed the name from a zombie to the more marketing-friendly term proxy. AutoCAD could also load a ‘picture’ of what the proxy looked like, but it could not be edited without exploding the geometry (turning it into lines, circles and arcs, removing the ‘intelligence’) or loading the specific ObjectARX application. This was pretty much the situation until the deployment of Autodesk’s Mechanical Desktop (MD) – an application that used ObjectARX and defined its own custom objects. MD sat on top of normal AutoCAD.
MAI - Mechanical Application Initiative
To support the Mechanical Desktop layer, Autodesk put together a group of world-class developers under the banner of the MAI (Mechanical Application Initiative). These developers were tasked with creating add-ons for MD, building on top of the new functions that were there. Very soon on, these developers realised that by using ObjectARX they could create objects, which would become proxy objects outside of their vertical application. (For instance, if you were using the Genius add-on to create a spring within a Mechanical Desktop session and were to save that to a DWG file). If you were to open that model in vanilla AutoCAD, a number of Mechanical Desktop proxies would appear, as well as Genius’ own proxy for the spring. If you were to open the DWG with a Mechanical Desktop version of AutoCAD, you would be able to edit the MD components but the Genius spring would still be a proxy. You need to load the Genius application layer to ‘intelligently’ edit Genius’ own custom object.
Seeing the problems when proxies occur, the MAI partners decided to limit themselves to only ever creating Mechanical Desktop objects – or at least geometry that could be understood by MD. So, even if you didn’t have the application for the spring, Mechanical Desktop wouldn’t see it as a proxy. In short these developers could see the compatibility problems that could be introduced within the new AutoCAD design environment.
New Developments
Moving forward with the release of R14 and the purchase of the US architectural developer, Softdesk, the scene was now set for Autodesk to develop and market the object-based Architectural Desktop. This solution, due for launch in the UK later this year, and even sooner in the States will create many new custom objects (walls, doors, windows and so on). If you were to load an Architectural Desktop model into a vanilla AutoCAD R14, all of these objects would be listed as proxies and the only way to edit them would be by exploding them into lines, circles and arcs, thus removing the round-trip object intelligence – totally defeating the object. A solution to enable standard AutoCAD R14 users to edit these Architectural Desktop models will obviously be required.
Talking to Autodesk in March this year, it said that it had ‘solved the proxy problem’ and had decided to give away the ObjectARX code that created the Architectural Desktop objects. Autodesk calls this the ‘Object Enabler’ and is a freely distributable plug-in for AutoCAD users. It will be about 2-4Mb and can be loaded by AutoCAD R14 to allow any user to fully edit every object that Architectural Desktop can create. The only thing the object enabler won’t be able to do is create new objects from scratch.
So if somebody did not want to buy Architectural Desktop, it would be possible to create a drawing which included all the objects that Architectural Desktop can make and then cut, paste and modify them into a new drawing! Autodesk assumes that for ease of use, customers would sooner buy the add-on. Though I’m sure with a little customisation know how and a digitising tablet this barrier could be overcome.
Ove Arup on objects
The CAD companies would have us believe that the architecture market has been crying out for object modelling for a long time. This may or may not be the case, but with over 22 companies estimated to be involved with one project at any time, data portability and integrity is paramount. It’s also important to win the backing of major industry players, so that’s where I went next.
Luckily I came across a company that had some first hand experience of the power and the limitations of Autodesk’s ObjectARX in a mixed CAD environment. I’m sure many of you know Ove Arup, one of the world’s leading architectural, civil and structural engineers, which has over 60 offices in 40 countries, employing over 5,000 people. The company uses many CAD systems, the mainstay being AutoCAD.
I visited Ove Arup’s offices in central London to meet Alec Milton who is CAD Development Manager and heads-up the company’s global AutoCAD implementation, also heading up the development of OvaCAD – its own in-house AutoCAD add-on.
First, Alec talked me through Arup’s experiences with custom objects. "When we first got wind of custom objects we got quite excited. We thought we could do all kinds of wonderful things with the technology. So straight away we started writing something called SteelWorks which was designed to produce custom steel objects that can be displayed in lots of different ways – an easily editable stick model, surfaces and then a whole 3D model. The excitement was there for a week or two and then we started to see the problems."
"The first problems were basic things like snapping to these objects. If we were designing a complex piece of steelwork, which could be highly curvaceous, calculating how to snap to a near point can get quite complex. Even if you were to snap to a midpoint instead, where is that midpoint? Is it the centroid of mass, the midpoint of the top surface or bottom surface? And this is something which is really simple."
"We also found, more worryingly that we couldn’t give the file to other people using AutoCAD. They couldn’t read it. We also had problems with ARX, problems that still exist today. If you write an ARX application and don’t cross the Ts and dot the Is and fail to get everything absolutely perfect, the application won’t expire quietly like it would with ADS, the system goes bang! AutoCAD crashes and work will be lost. At least when ADS applications crash, your AutoCAD session is usually left standing. "
"So we decided to stick to basic ADS and LISP or write in C++ but as an ActiveX program, so we drive AutoCAD from the outside world. Also the portability this method offers means we could run this on another CAD system, like IntelliCAD for instance. "
"We are really keen on objects, we write lots of object-oriented code. However, the ObjectARX objects we are very cautious about. We have produced a standard letter for our managers to send out to clients to say that we are aware of this problem. It says something along the lines of, ‘Before a project commences and any data exchange agreements have been made, the data exchange process must be tested. Should problems appear either at the testing stage or later during project execution, Ove Arup & Partners will require the originator to replace the custom objects with standard AutoCAD entities’."
From talking with Alec and seeing the potential problems proxies hold for AutoCAD users, it’s not surprising for Ove Arup & Partners to exclude them from its drawing database. Also of note is that the company makes extensive use of AutoCAD LT, where there's another twist in the tale.
Objects in LT?
AutoCAD LT has proved to be very popular. There’s a compelling reason for this - a version of AutoCAD that does 80% of its big brother for 16% of the cost. The only serious limitations are its inability to run AutoLISP or ADS developed applications. Many companies like to use LT for a budget seat where necessary and is a good choice due to the 100% DWG compatibility that Autodesk prides itself on. The latest version of LT actually does contain support for ObjectARX but Autodesk reserves the use of this to its own in-house uses. Here, the danger of allowing LT to have powerful customisation capability will obviously provide competition for full-blown AutoCAD sales.
From talking to Autodesk it seems as though an Architectural Desktop Object Enabler is on the cards sometime in the future but there are no plans to support enablers from third-party developers. So, for now, LT will not be able to edit models created in Architectural Desktop (until an LT Object Enabler is distributed) and in the long term any third-party objects created with ObjectARX e.g. a HVAC add-on, will only come across as proxy data. The picture is obviously incomplete. Even if the AD Object Enabler was available, if you were to load a model which was created with Architectural Desktop and this mythical ObjectARX HVAC application, LT would create a model which was half editable objects and half non-editable proxies! If you were to ignore the initial warnings on loading the file, and then move an Architectural Desktop wall, which one of the HVAC components was aligned to, the lack of the HVAC enabler would mean that the ductwork would not move as it should. If you were to explode the ductwork you would remove its intelligence for good. This is a simple example but in a complex model this could lead to a corrupt model, losing its intelligent links and related dependencies.
Importing Proxies
Alec test loaded DWGs created by a beta version of Architectural Desktop (i.e. an object-based model) into a variety of commonly available CAD and viewing packages. Here’s a brief summary:
MicroStation SE gave no warnings of proxies and displayed no graphics at all IntelliCAD gave no warning of custom objects and similarly gave an empty display
Visio 5 gave no warning but if you picked the empty sheet displayed a boundary box, double-clicking on this launched IntelliCAD which gave a blank screen!
AutoManager View from Cyco gave no warning of proxies and just displayed the grid object. Autodesk View 2.0 gave no warning of custom objects but displayed the 3D proxy views, though not perfectly – it was able to snap to the graphics and get distance measurements.
One worrying result came from Autodesk’s own LT 97, which didn’t give a warning that the file contained custom objects. It loaded the file with some graphical omissions but it wasn’t possible to snap to any of the graphics. LT97 could select individual objects but you could only list their properties and the objects could not be edited. It appears that proxies will be introduced into an unprepared world of CAD solutions that contain ‘DWG’ readers.
Alec also loaded the Architectural Desktop DWG into a vanilla AutoCAD R14. On loading, R14 halted and displayed a proxy warning dialogue box listing the number of proxies and the application that originally created them. It wasn’t possible to snap, select or edit these proxies once loaded but you could Zoom. The next process was to save this file of proxies as an R12 DWG.
Loading this R12 DWG took ages in R12, AutoCAD LT (version 1) and IntelliCAD. However, the display looked better, as you could snap, select and edit entities. However, on closer inspection every object had been turned into single lines. A single door, that should have been a single Polyline had been turned into 24 lines, circles were tessellated into 420 individual lines and the walls were mere outlines with no thickness. To top it all off, everything was exploded onto layer 0. The original model contained only 50 custom objects and the transfer to an R12 DWG managed to produce no less than 15,542 lines! One hopes this doesn’t happen with DWG conversion in the shipping version of Architectural Desktop.
An Object Myth
From talking to a number of users there seems to be a common misconception that applications written with ObjectARX, or object models in general, interoperate. That is to say, all the objects (walls, doors, ducting, steelwork, electrical and so on) that are contained in a model will automatically interoperate with each other within building regulations.
This is certainly NOT the case. Autodesk is currently courting its architectural developers to build on top of Architectural Desktop’s base objects (e.g. walls). So, a HVAC developer’s ducting objects would intelligently interact with an AD wall. If you were to build a single architectural model, containing all the details, using three packages – AD, a third-party HVAC add-on and a third-party steelwork solution, it’s highly unlikely that the steel objects and the HVAC objects will be capable of interacting with one another. Unless otherwise stated treat all objects created by third-party add-ons for Architectural Desktop as independent of each other. Autodesk has stated that a number of developers from different architectural industries that are attempting to work together may, in the future, produce interoperable solutions. This list of developers has not yet been collated.
Another fundamental shortcoming with Architectural Desktop is that it does not currently support something termed Object Management Services (OMS). These OMS are common in some other object-based modelers where application interoperability is key. One example of a service would be registering a relationship between two independently created objects -- like aligning a column created by one application with a grid intersection created by another application. So when a grid line (and thus the intersection) moves, the column is notified and can automatically re-align itself. I expect to see this in future versions of Architectural Desktop.
IAI and IFCs
When it comes to translating models between different CAD systems, the stock answer from the sales arms of all the CAD vendors involved appears to look to the International Alliance for Interoperability’s Industry Foundation Classes. In my view, this particular sales pitch is highly hypocritical, for while CAD dealers will be extolling the virtues of IFCs from day one, there remains an undercurrent of 'no confidence' in the IAI from within the upper echelons of the CAD software industry.
Alec Milton of Ove Arup, shares the industry view, "I find the way CAD vendors talk about the IFCs particularly irritating, as whenever we question how interoperability is going to be solved, the reply is always ‘well the IFCs will sort this out’. There seems to be little appreciation that the IFCs only define properties but not the actual display."
"For example, if you write out a symbol of a fire extinguisher from AutoCAD as a custom object within an IFC file and then you were to send that to someone in Malaysia using MicroStation, what would it look like? Let’s say my UK version of AutoCAD’s representation of a fire extinguisher is a circle with a cross but in Malaysia using MicroStation it’s a box within a circle. You can get all sorts of problems when symbology isn’t the same across a project. "
"This of course assumes that AutoCAD can export IFC's and MicroStation can import all the same classes. Versioning is going to be a big problem here."
"On top of that, what happens if it’s an international project and the client wants to use the Japanese standard symbol? Currently if a client wants to use a specific set of symbols then fine we can guarantee that, using today’s technology we know that wherever you print it out in the world everything will look the same."
Autodesk is attempting to differentiate its ‘proxies’ from being an ‘intelligent zombie’ (which is surely an oxymoron?) because in the next incarnation you will be able to copy and array a proxy graphic. However, if you were to model a building using objects or details that had not yet been given a foundation class, like a loft hatch, an IFC translation would create an ‘ifcproxy’ graphic of this i.e. a ‘dumb’ vector image. The devil is in the details and it’s these that will create integrity problems when it comes to data transfer by IFCs. (The next chapter will have more details on the efforts of the IAI)
So, if the IAI can’t currently guarantee a 100% transfer of objects from one CAD system to another, how will the object data circulate in a mixed CAD environment? I’m afraid that for now it won’t. From what I can see, objects will work best in an enclosed environment; a company where everyone runs the same CAD system and the same revision of applications. The only way you will be able to pass intelligent objects to other users, guaranteeing 100% data integrity is if the other company uses the identical CAD system and applications as you. So there’s no change from what the industry currently offers. In fact it will probably be worse, as those that move to object modelling will no doubt want to keep their database’s ‘intelligence’ and will demand that contractors use the identical system, more often than now.
Who benefits?
I am positive that all the developers of all these object CAD engines realise that objects can only work in an enclosed system. This will, in turn, lock their customers more securely into a reliance on their software and object file format. The net result will force company supply chains to standardise on one agreed system, which will generate more sales for that particular vendor.
Alec Milton of Ove Arup and partners found this out at first hand, " Autodesk tend to forget that there are other CAD systems on the market. I recently raised the problem of data exchange with ARX objects when speaking to one of their American representatives. I was explaining that a MicroStation user would not be able to get any useful information from a drawing containing ARX objects. His response was 'why can't they all run AutoCAD?', and he wasn't joking ".
There’s also a chance that third-party-developers may choose not to create Objects Enablers for their products. This would force anyone wishing to ‘intelligently’ edit a DWG to buy a copy of the application. Developer's and vendor's, while appearing greedy, will not loose any sleep over this as from there perspective, they will see this as a perfectly justifiable protection of their intellectual property rights. In other words, if you want to benefit from the advancements in CAD technology provided by the developer, then you must pay for them - not only with the original system that created the objects within your design scheme, but also on all systems that view and edit the drawings. And here, that may well include all the CAD seats belonging to all 22 AEC contractors involved.
From the user's perspective who is accustomed to the luxury of data transportability without additional cost, it’s not difficult to imagine that these extra financial pressures that could conjure up feelings of extortion or blackmail.
From an ethical perspective, developers shouldn’t need reminding that drawings are created and owned by their customers and rights to editing or viewing these drawings should be left to the drawing office manager. From my research, this reminder may also need to be targeted at the CAD vendors themselves.
Conclusions
In the short term, I cannot see how the introduction of proxies in the AutoCAD drawing file format is a ‘good thing’, specifically within an architectural environment, where data needs to be shared amongst many companies from a wide variety of disciplines. The standards are not in place to guarantee anything like successful data transfer, unless the whole supply chain moves to a solution from one vendor.
While it seems that Autodesk will develop an Architectural Desktop ‘Object Enabler’ for AutoCAD and perhaps for LT, this will only allow Architectural Desktop objects to be edited, nobody else’s. While third-party developers are being asked by Autodesk to provide ‘enablers’ for their custom objects, they are under no obligation to do so and even these will only work with full-blown AutoCAD R14. From talking with Carl Bass (see box out), enabling objects in LT seems like an afterthought, and here, it would seem that Autodesk is going to keep the third party objects from being enabled for use in LT. So if you are using an application for AutoCAD that isn’t created by Autodesk, there may be no such thing as a ‘cheap seat’.
In a rush to get an object modeller on the market, Autodesk has gone for an evolutionary approach. This means that, for the near future, the AutoCAD architectural user base will increasingly become a mixture of the traditional ’dumb’ vector users and object modellers. Unfortunately due to the way the new technology has been implemented, all this data is stored in the same file format, DWG, combining standard entities with custom objects (omitting the object definitions). While objects can be converted back to lines, circles and arcs (though in our AD beta tests not to any satisfaction), this does defeat the purpose of adopting objects in the first place and will not please the originator of the model when handed back, disassembled.
From my research, I view that Autodesk’s evolutionary approach to implementing object modelling will lead to data inconsistencies and a degree of turbulence within the AutoCAD architectural installed base. Object Enablers are not a solution but a fourth attempt at a zombie fix, to use an ‘Americanism’, a band-aid on a bullet wound. I would have preferred to see at least a new file format, if not a wholly different CAD package.
To really enjoy the benefits of object modelling the first requirement seems to be an enclosed environment, a server with advanced data management capabilities, serving data and parent application together. The main CAD vendors appear to comply with this notion but are taking disparate approaches and working on different time scales.
The next stage
With Release 15 and beyond Autodesk is promising to introduce a project file, which will deliver object data and enablers together, hopefully stopping proxy problems. It’s also obvious that more tools are necessary to manage this data and perhaps a client-server approach to contain a company’s object modelling system. This ‘ModelServer’ strategy has been championed by Bentley Systems, whose server-based object system is due for launch in the next few months.
The next chapter will look at the technical issues involved in the managing the objects in the model database, managing the applications that create the objects, concurrent use of that database and implementing Project Servers.
All rights reserved to Electronic Design Automation LTD 1999
Any queries to webmonkey: al@edaltd.co.uk
