Cadetron and Solid Modeling

By mid-1986 there was little disagreement with the assertion that solid modeling would be a key component of the company's future product mix. But as we studied the requirements of the mechanical parts design market, which presently makes up the largest part of this market, it was also clear that even if AutoCAD could be extended into some kind of solid modeler, it would not really meet the needs of that market. Eric Lyons was the leader in researching this market, and in this paper he recommended that we investigate purchasing Cadetron which, in March of 1987, we did. As AutoSolid becomes more and more central to our strategy in the mechanical engineering market and begins to contribute a growing component of Autodesk's revenues, it will be fulfilling the promise that this paper evokes.

We stand at a crossroads. We are about to be dragged—kicking and screaming—into a world we know little about: the world of engineering modeling. This, in itself, poses little significant threat. After all, no one knew anything about drafting when this company started out. But we had an advantage—we were the first to do it [on a PC]. So there was some leeway, some time to make up for the features we lacked. We no longer have that luxury. Companies—big companies—that know and understand engineering modeling have seen that the PC isn't a toy; indeed, it and its successors are becoming the platforms on which their products are designed to run. Yikes.

We underestimated the importance of modeling over a year ago. We have been working on a generalized 3D version of AutoCAD for some time. In my “3D design paper” of May 27, I described 20 features that would bring us to a level equivalent to our competition at that time. We have implemented only a few; the hard ones are yet to be even started. And we have added things that never appeared on the list—primitive solid objects that are unrelated to each other. So we still have some work to do. But in the six months since I wrote that paper, some trends have emerged.

I have seen solids modeling, and it is the future. For years the skeptics have criticized solids as impractical, compute intensive, and inflexible. “You can't cut chips with solids,” they'd say, or “sure they're fun, but what can you do with the model when you're done”? Well, they were wrong. Solids modeling is the next step in the evolution of CAD/CAM as surely as 3D followed 2D. Perhaps not for the better, but inevitable nonetheless. So we are faced with another problem: will we let solids get away from us as 3D did? Will we be sitting here in another year, wishing we had a solid modeler, and being run over by our competitors as we try desperately to catch up?

First of all, why is solids modeling such a big deal? See the attached article that describes some of its advantages over the more traditional surface modeling systems. Suffice it to say that its greatest advantage is that it is nearly impossible to create unmanufacturable objects with solids. Not completely impossible, but much less possible. In addition, analysis of solids is much easier and more accurate than with surfaces. So that's the big advantage. Solid modelers do require a fair amount of compute power and storage, however, so they aren't so great for AEC applications (a building described as a set of solids—including all of its components—would quickly be unmanageable on any of today's computers), but for discrete manufacturers they can be a boon. And there are a lot of discrete manufacturers out there.

The conclusion to be drawn here is that we need a solid modeler, sold by Autodesk, interfaced to AutoCAD, within a year. I rule out the possibility of making it part of AutoCAD within that time; 3D has taught us enough of that. Besides, solids is still frequently thought of as an application, and therefore the concept of a solids package outside of AutoCAD is fairly easy to sell.

So, what should a solids package do? Obviously, there is lots of room for definition—you can buy a $50 solids package for the Atari, or you can buy a $100,000 Medusa for the VAX. What's in between? First, consider that solids is a design application. Designers are interested in how objects behave. So beyond the ability to create an accurate geometric model using CSG or B-REP techniques, the thing is useless without being able to derive mass property information from the model. And since a large portion of engineering is spent determining the effects of loads, strains, and temperature variations on parts, the model should be efficiently interfaced to a FEM package and mesh generator. Also, since 80% of all parts manufactured in the U.S. are still done from engineering drawings, there should be some way to detail the finished part with a drafting package (AutoCAD is a decent choice). Ideally, this detailing step should be augmented with numerically controlled machine tool program simulation and verification for automatic manufacturing. And, of course, the user should be able to visualize the model in a realistic form. So that's what a solids package should do. Some companies have based their products on all or part of this definition. Aries Technology has spent 2 years and $15 million to bring a system to market that does solids, material properties, and FEM interfacing. A whole industry is spawning that the analysts call MCAE—mechanical computer aided engineering. Within a year, we will be competing with these people for the middle range of CAD/CAM.

Okay, we need a solids system. How does that affect our current developments in 3D? Well, we should obviously finish the development of 3D AutoCAD. With the exception of the funny little solid primitives we have defined, what we are working on is really a 3D drafting system. It is a way to define a wireframe model, view it, and detail it from any orientation. This is a necessary function when we do have a solids package, as well as being required for AEC applications. Where we go from there (surfaces, properties, etc.) depends on some decisions we make with respect to a modeler.

How Do We Do It?

We have two alternatives:

1. We write a solids package ourselves.
2. We buy one from somebody.

If we choose option 1, I don't believe we can acquire the knowledge necessary to write one from scratch in the time we must, so we must get a head start from somewhere. One possibility is to buy a one-time PADL-2 license from the Production Automation Project-80k lines of Fortran (FLEX, actually), designed to run on a VAX, $50,000—and convert it into something usable. Another possibility is to license the geometry libraries available from Applied Geometry. These libraries represent, perhaps, 15% of a working solids package. Just add code (à la Visual Engineering).

A third possibility is a buyout of a company who has already done all this stuff, have them interface their product to AutoCAD, and sell it as our solids package. That company is Cadetron. Attached is some information on their company and their product. What follows is a proposal for the acquisition of their company and their product, and how it fits into our future: taking over this industry once again.

Product Positioning

Given that we acquire this product, how do we fit it into our existing product line, and what problems does it solve for us? First of all, the modeler would exist as a separate product, working as a pre-processor to AutoCAD (more accurately, AutoCAD would be a post-processor to it). It is intended for the mechanical engineering/manufacturing market. Parts can be designed, analyzed and realistically visualized using this package, then sent to AutoCAD (as either a fully 3D model for future 3D, or as a 2D “drawing” file) for detailing. The model can also be interfaced to FEA programs by using the optional automatic mesh generator. Eventually (they currently have this stuff under development), NC toolpath verification and simulation can be done on the model, and surface modeling (for things like car bodies and thin shells) can be done on the modeling side. AutoCAD is used only for detailing, in both 2D and 3D.

Also, AutoCAD 3D is used for virtually all AEC applications. Facilities management, piping, architecture, etc, are all done using the wire frame modeling in AutoCAD. We do not invest in adding surface modeling capabilities to AutoCAD, nor do we make our funny little solid primitives into a fully general solids system. AutoShade is still the AutoCAD rendering package, and is used by people who don't want to do mechanical solids applications. If you are an architect, you buy AutoCAD (and AutoCAD AEC stuff). If you are a discrete manufacturer (you make parts), you buy SolidWorks (or whatever we want to call it) and its add-ons, along with AutoCAD for detailing. Perhaps we could even use AutoCAD as a front end to the solids package: we can create our funny little solids, rotate them, scale them, position them, then pass them on to SolidWorks for Booleans and analysis.

Eventually, the two products converge into one. They share a common user interface and a common database.

With this combination—the industry standard drafting software, the world's most powerful solids modeling software—all sold by the world's lowest cost CAD distribution network, people like Aries don't stand a chance. They will be forced out of the market. Computervision will shake in their already soggy boots. Intergraph will die a slow, horrible death, buried in caskets made of Interpro 32C boxes. Autodesk will prevail as the dominant force in CAD/CAM worldwide.

How Does All This Really Work?

Obviously, there are some things to be worked out. How much do they cost, how does the interface work, what modifications do they need to do to their product, how do we resolve the different operating system problem, making them understand what really low cost software should be, etc. A total buyout seems like the best opportunity to control all the marketing (especially) and the development direction. But I think it's important that we don't screw up a good thing—they have a team of 6 programmers who have successfully converted some of the most sophisticated engineering code in existence (while considerably optimizing it) to a small machine. Us telling them what to do with solids would be like them telling us how DIMZIN should work. We need to look at their commitments, review their development projects, and define a set of projects that will result in our two products being integrated in a timely fashion. We need to determine the resources of each of our respective development staffs to make such events occur. I feel confident that we can do this without draining resources from our current (difficult) development agenda. It will take some coordination and supervision, but not all the resources of a Greg or Kern or John. And I want to lead it.