|
We have used AutoCAD® at CSA for many years now, and I have consistently recommended it to others. A variety of reasons lie behind our use and recommendations. One important one is the fact that AutoCAD has become such a standard that other CAD programs have been modified to use AutoCAD drawing files. This seems an important advance because it means that it will be easier to share CAD models, even though different programs have been used to make them. Of course, this is also an clear statement of the dominance of AutoCAD in the market.
I have recently learned, however, that AutoCAD models are not so easily shared as I had assumed, and comments about some questions related to that issue were included in the review of AutoSurf® in the last Newsletter("A Review of AutoSurf - Plus Some Ruminations about File Formats for Scholars"). As this situation has become more clear to me, my level of concern has risen. To explain, I must define the term that lies at the heart of the matter, file format.
A file format is a specific arrangement of data in a file. The arrangement must be specified completely so that program developers know how to encode information to put it into the file and how to decode that information to retrieve it from the file. A word processor file, for instance, must be formatted in a specific way to indicate that a bit of text is to be shown in boldface or that a certain passage is a footnote attached to the text in a given place. Similarly, a properly formatted CAD file must encode and decode the bits of information that define a line or a circle according to the specifications of the format. We all see how specific these formats are when we try to open a file with the wrong program. That does not work.
AutoCAD's file format - called DWG from the DOS extension indicating an AutoCAD file - is somewhat different. The format specifications, of course, indicate how objects such as lines or circles should be encoded in a file; however, the format specifications also permit customized objects to be put into the file, objects unknown to Autodesk (the company that produces AutoCAD). These are known as custom objects.
In theory, being able to add custom objects to a file is a fine thing. It permits the format to be expanded rapidly. In practice, however, it creates a problem. Not all programs that use DWG files can decode all custom objects. That is, many programs can encode and decode DWG files. Some of them encode and decode certain custom objects; others encode and decode different custom objects; still others can encode and decode no custom objects. Confusion is inevitable. What custom objects can the programs you use encode or decode?
I am not certain how pervasive the confusion is, but I have experienced enough confusion myself to be concerned. First, I have seen that at least one type of custom surface made by AutoSurf (an Autodesk program) and encoded into a DWG file is ignored by AutoCAD when it decodes the file. When such a surface was made, there was no warning to indicate that the surface would be ignored by AutoCAD. Nor was there a warning I saw in the manual. No warning appeared when I opened the file in AutoCAD; so there was no obvious way to realize that anything was missing.
I found that I could simplify the surfaces with an AutoSurf command and save the model again. Then the surfaces were visible in AutoCAD, but they were not treated as surfaces (they would not hide things behind them), and they could not be edited. I could not even select a point on either surface. The only thing I could do was erase them.
Using the command to get information about one of them, I was told that it was a "zombie;" layer and color were stated, as well as the fact that the surface was created by AutoSurf. The object type in AutoSurf was also named, but neither position nor dimensions were given.
Without going into all the niceties of the DWG file format, it should be clear from the foregoing that we have a serious problem. Some DWG files seem to be more equal than others. Some have more information; others less. Some can, I assume, be completely decoded by any program that accepts DWG files; others cannot. No program, so far as I know, can decode all custom objects, because Autodesk maintains no registry of all custom objects.
Since those of us who are trying to use AutoCAD models for scholarship must share our DWG files with colleagues in order to carry out our work, what are we to do? Dare we use programs that create custom objects to simplify our work? If not, how do we know which programs, other than AutoCAD itself, create no custom objects? Can we accept models that include custom objects? I think we must take the most conservative path - use no programs that create custom objects and accept no models with custom objects. Given the current state of affairs, no other course is safe. If we create models with objects that others cannot see, we risk confusing our colleagues (and encouraging them to assume we have constructed an inadequate model). If we use such models, we run the risk of misunderstanding them (and assuming our colleagues have omitted something). This does not change my recommendation of AutoCAD, but it does mean that I will not use any other program to assist in model building unless I am certain that it will create no custom objects (which will generally require a letter to the manufacturer). It also means that I will search a bit harder for CAD programs that do not have this problem (although the arrival of WalkThrough, see the previous article makes the DWG format very desirable) - while I will try to convey the importance of this problem to people at Autodesk.
For other Newsletter articles concerning the use of CAD in archaeology and architectural history, consult the subject index.
Table of Contents for the Feb, 1997 issue of the CSA Newsletter (Vol. 9, no. 4)
Table of Contents for all CSA Newsletter issues on the Web