The formats used by SFF machines to accept external geometry consist of a mathematical representation of the geometry and a data description in a file.
The boundary surface of a solid can be expressed in a variety of geometric forms: Bezier, nonuniform rational B-spline (NURBS), Coons patch, Gordon patch, planar patch, cyclide, and other blending surfaces, lofting surfaces defined by specific procedures, and implicit forms, to name just a few. For each form it accepts, the SFF machine must maintain a separate set of geometry manipulation routines or utilities, even in cases where the form is a special case of another, if speed is an issue. (There is a time penalty incurred when slicing simple triangles with a generalized complex slicing algorithm designed for NURBS surfaces.) This means that many of the CAD geometry utilities that already exist in the different vendor CAD workstations must be duplicated in the SFF machine. The need for duplication is further exacerbated by the fact that CAD vendors generally do not make public all aspects of their internal geometries.
The ideal compromise, and the one often followed today, is to have SFF machines accept one common geometric form -- thus needing only one set of slicing and other geometric utilities -- and shift to the CAD vendors the burden of translating their internal, sometimes proprietary, math forms to this accepted common form. Conceptually, the problem reduces to one of approximating by a single geometric form all other geometric math forms, as well as their intersection curves, trim curves, and blends -- hardly an optimal solution.
What "common" math form to use? One choice is the most general math form possible, which will be discussed later in the section on the STEP standard. The other extreme is to choose the simplest of all the geometric surface forms, the triangular element. (Some argue that slices are a simpler and more flexible representation.) The triangular approximation consists of sampling the original surface and connecting the surface sample points with triangles. The simplicity of the triangle geometry is offset by the huge numbers of very small triangles needed for a good approximation, and the opportunity for numerical and other approximation errors (some triangles may degenerate to lines).
The process of approximating a surface by triangular facets, sometimes referred to as tessellation, is used extensively in computer graphics, where special integrated circuit chips have been designed to perform this function. Triangular approximations of smooth surfaces work well for color rendering and shading on graphic displays, because the surface is continually subdivided until the triangles are smaller than a screen pixel, and then each triangle is color-blended across its edges to give the appearance of a smooth shaded surface. Unfortunately, slope discontinuity across the edges of adjacent triangles cannot be disguised so easily in physical parts, and this has downstream processing ramifications.
The simplest scheme for a data format is to represent the solid as a sequence of surfaces. A surface is represented as a sequence of triangle elements, with no regard to order or topology. A triangle element is represented as a sequence of its three vertices and its outward (from the surface)-pointing normal vector, defined according to the right hand rule by the order of the vertex sequence (Fig. 8.3). This representation, along with its data types, delimiters, and other file information is called the STL format, introduced originally by 3D Systems, Inc., in 1988. It is the de facto standard for transferring solid geometric models to SFF machines.
Although many SFF machine vendors offer their own formats (summarized in Fig. 8.4), they all accept STL. Since 3D Systems was the first and remains today the major vendor in the marketplace, its format will continue to dominate. The small enhancements in format offered by others will not tilt the balance. Based on the evolution of CAD formats, the key enabler of change will be a motivated and vocal user community.
Table 8.3 lists the CAD modelers being used at the sites visited by the JTEC/WTEC panel. As one would expect, many of the solid modelers popular in the United States are also popular in Europe and Japan. The reason is simply that U.S. CAD vendors dominate the commercial market. Whereas many U.S. companies now use vendor-supplied CAD systems, Japanese companies continue to develop proprietary systems (or portions of systems). Most European companies use commercial modelers, except for some large companies like Daimler Benz.
The desire to develop proprietary CAD and RP software is reminiscent of the "reincarnation of the wheel" phenomenon, which is characteristic of fast-moving fields. It was certainly true in commercial CAD during its rapid growth in the late 1970s and early 1980s. CAD may be used as an example to illustrate the dynamics. Initially, large technically based companies developed their own internal CAD systems because their specific internal needs were not being met by the emerging commercial vendors. Using their formidable state-of-the-art internal expertise in applications and computers, these companies were able to create CAD environments that not only went well beyond the capabilities of commercial systems, but also were tuned to their internal needs. However, when these CAD systems became operational, the general tendency was to scale back further enhancement because, after all, the system is only a means to an end and not the main product of the company. Meanwhile, the commercial CAD vendors continued to innovate and ultimately surpassed the capabilities of the user companies, causing senior management to abandon aging internal systems for state-of-the-art commercial systems.
This cycle continues to repeat itself. As the CAD vendor's application base continues to grow and diversify, its support has to harmonize the needs of a larger application base. Since the vendor can no longer dedicate sufficient resources to company-specific enhancements and meet the company's rigid time schedules, the company launches a new internal development effort to create its next-generation CAD environment aimed specifically at its current needs.
The trend in rapid product development today is toward a broad system of many integrated functions. CAD is but one cog in this big product development wheel. Consequently, enhancements in CAD are judged not in isolation, but in terms of their effect on overall system functionality, throughput, and stability. A new geometric engine may not be useful if it means redeveloping existing geometric utilities, scrapping the database system, and launching a major training program. Ultimately, such considerations will be necessary for those RP systems used in engineering and manufacturing.
Today, virtually every commercial CAD vendor provides a CAD post-processor for translating internally represented CAD solid models into faceted solid models for SFF machines. Additional modelers that provide STL include Aries Concept Solids from Aries Technologies; Bravo3 from Applicon; CADKEY from Cadkey, Inc.; and the French modeler EUCLID from Matra Datavision. A number of PC-based 3D modelers originally developed for 3D graphics applications now offer STL output capability.
Although many agree that the STL format leaves much to be desired, there is no unanimity on its replacement (Dolenc and Mäkelä 1995; Jamieson and Hacker 1995). Since there is no single all-encompassing general math form that includes all other practical geometric surfaces as special cases, then it makes sense to focus on those math forms that support a large application base. The evolving STEP standard for the exchange of product data, based on NURBS geometry, is the most promising candidate, because of its growing acceptance and use in engineering and manufacturing applications.
NURBS geometry was originally promoted and developed by the aircraft industry, specifically by Boeing, because conic sections, which are very important in the aerodynamic design of airplanes, are represented exactly by NURBS. With its great flexibility and power, however, NURBS has disadvantages as well: it is more difficult to master; pathological and practically nonrealizable surfaces are easily generated; and some theoretical aspects are still thorny. Regardless, NURBS has caught on and is rapidly becoming the most widely used surface form, including the computer graphics standard, PHIGS (Programmers Hierarchical Interactive Graphics System).
In the United States, the CAD community has been developing standards for exchanging data among CAD systems since 1979 when Boeing, GE, and NIST (National Institute of Standards and Technology, then known as the National Bureau of Standards) joined forces to lead a national effort to develop a neutral file format for representing engineering drawings. The effort led ultimately to IGES (Initial Graphics Exchange Specification), which became a U.S. national standard in 1981. See the U.S. Product Data Association (http://uspro.scra.org/) and STEP Tools, Inc. (http://www.steptools.com/) web sites for details. The current version, IGES 5.2 transcends its original manifestation as a standard for exchanging 2D graphical drawings and includes 3D surfaces and solids. Similar efforts in Europe led to the German DIN 66301 standard, VDA-FS (Verband de Automobilindustrie 1987, http://www.tailormade.com/vda_over.htm), and the French AFNOR Z68-300 standard, SET (Standard d'Échange et de Transfert).
All of these CAD standards efforts are now being superseded by STEP,2 a much more extensive data exchange standard that will eventually extend beyond product data and include process and resource data. The first phase of STEP was approved in late 1994 as international standard ISO 10303 by the International Standards Organization (ISO) (http://www.igd.fhg.de/www/igd-a2/hyperstep/iso-10303/gen.htm and http://www.scra.org/pdesinc.html). Most CAD vendors are committed to supporting STEP. (One can think of IGES as specifying a neutral flat file format, while STEP specifies the associativities of a neutral database.) The STEP standard provides extensibility to many application domains through a structure called "application protocols." Each application domain has its own application protocol, with substantial sharing of common core functions.
There is strong interest in developing a STEP application protocol for exchanging CAD data with SFF machines. In Japan, Professors Kishinami and Kimura (http://www.cim.pe.u-tokyo.ac.jp/index-j.html), who have interests in systems aspects of rapid prototyping, are also deeply involved in STEP activities. Preliminary work on a STEP application protocol for SFF machines was begun in 1993 as part of the Rapid Product Realization project in the international Intelligent Manufacturing Systems (IMS) program, led by United Technologies in the United States, Daimler Benz in Germany, and other companies in other countries. See IMS Test Case #6 1994 (January and June), and Aubin (1994). SFF standards continue to be promoted in the United States by the Rapid Prototyping Association of the Society of Manufacturing Engineers (http://www.sme.org/), NIST, and the DOE Sandia National Labs. Gilman and Rock (1995) propose to integrate more closely into the design process using STEP as the vehicle of integration.
For many reasons, 2D slice data is a viable format. Some believe a 2D contour representation is more basic than a 3D solid model. The founders of one German company, Fockele and Schwarze (1994), believe that the 2D contour representation allows their company to build bigger and more precise parts. Others suggest it is easier to work with. Management of the Belgium software company Materialise (http://www.materialise.com/) takes this position: "At the primary level, each RP machine operates on the basis of stacks of 2-dimensional drawings. 2D contour software enables the user to work efficiently with this data stream, thus solving special problems and enabling special applications. ... By tackling the interfacing problem at the contour level, contour software is able to solve all problems with bad STL files." Finally and most importantly, 2D data from medical scan devices represent the tip of the iceberg for a vast biomedical field that promises to be a key application area for RP.
European activity in 2D formats is motivated in good measure by biomedical applications (implants, operation planning), but also by reverse engineering applications utilizing laser and other scanning devices. Technical interests range from general boundary curve forms (beyond polylines) to more flexible file structures. Rather than tessellate a surface and then slice the tessellated surface, why not slice the original surface (direct slicing) and then approximate the contour curves with polylines? Some feel this process reduces error, produces better surfaces, and results in smaller files (Ganesan and Fadel 1994; Vuyyuru et al. 1994; and Jamieson and Hacker 1995). German companies Fockele and Schwarze (1994) and CENIT GmbH (http://www.cenit.de/index_e.htm) use direct slicing.
The requirements for a flexible and vendor-independent format led to the development of the Common Layer Interface (CLI) format by a consortium of European countries organized under the EEC research program Basic Research in Industrial Technologies for Europe/European Research on Advanced Materials (BRITE EuRAM 1994). The goal of CLI was a flexible format that applies to all RP technologies, permits user-specific data (such as patient orientation in CT scans), and allows data transfer among a wide range of applications. User-specific data is included in the header section. The geometry section consists of an ordered (ascending) sequence of layers and their respective heights. The boundaries (outside, plus holes) of each layer are defined by closed polylines, with the "inside" or "material" side always on the left as the polyline coordinates are traversed. CLI supports both ASCII and BIN formats (http://www.cranfield.ac.uk/aero/rapid/CLI/cli_v20.html). Its first major application area is medical scan data.
The CLI format is now being supported by the European Action on Rapid Prototyping (EARP). EOS's (Electro-Optical Systems) layer data exchange software in EOSOFT is based on the CLI format. Materialise offers a range of software for RP, including software to generate parts directly from CT (computed tomography) and MRI (magnetic resonance interferometry) scans. Materialise's MIMICS software interpolates data from medical scanners, as described later in the section on RP Software.
There is still some concern that CLI (also the 3D Systems slice format, SLC) is still not flexible enough to be a standard (Dolenc and Mäkelä 1995). CLI seems to be biased toward fluid-based processes and dominated by medical scan data applications. An experimental data exchange format proposed by Dolenc and Mäkelä (1992), called Layer Exchange ASCII Format (LEAF), addresses these and other shortcomings such as flexibility, loss of information, lack of user control, ambiguity, impractical assumptions, and process dependency. LEAF is an experimental tool for researchers to promote standardization and is being developed further by researchers at the Fraunhofer Institute for Manufacturing Engineering and Automation in Stuttgart.
Daimler Benz' ZYRCO CAD software is compatible with CLI and STL, but the company prefers STL. Fockele and Schwarze, on the other hand, builds 3D parts from contours.
The Japanese are using the Hewlett-Packard Graphics Language (HPGL) format for representing 2D slice data. HPGL is the de facto standard for 2D plotting, where the data is represented in a vector format: start point coordinates, end point coordinates, pen up/down. INCS is developing software that interpolates and smoothes the CT slice data into an STL model for use in maxial facial reconstruction surgery.
SLC is 3D Systems' contour data format for importing external slice data, and SLI is the company's machine-specific 2D format for the vector commands that control the laser beam.
The Cubital Facet List (CFL) format is based on a polygon-based representation consisting of n-sided polygons that can have multiple holes (Cubital, Ltd. n.d.). The format avoids redundant vertex information and maintains topological consistency. CFL consists of a header and fields containing the total number of vertices (points) and facets in the object, a numbered sequence of vertex coordinates, numbered facets (with number of holes), and pointers back to their respective vertices. An example is given in Fadel and Kirschman (1995).
Fig. 8.4 summarizes the various 2D and 3D formats being used today in Europe and Japan.
The Bremen Institute for Industrial Technology and Applied Work Science (BIBA) has opened a web dialog on replacing the STL format with the Virtual Reality Modeling Language (VRML) format (http://www.biba.uni-bremen.de/users/bau/s2v.html). VRML is an evolving standard for describing multiparticipant interactive three-dimensional scenes networked via the global Internet and hyperlinked with the World Wide Web (http://www.sdsc.edu/vrml/ and http://vrml.wired.com/). VRML is based on the Open Inventor ASCII File Format from Silicon Graphics, Inc., which supports descriptions of computer graphics 3D scenes with polygonally rendered objects, lighting, materials, ambient properties, and realism effects (http://vrml.sgi.com/moving-worlds/). VRML, in the near term, extends this base to support multiuser network interaction, animation, and scripting.
Advocates of abandoning STL point out that VRML deals with the bigger picture: the 3D extension of the World Wide Web, the future 3D telecommunication and networking standard, which could also become the standard interface for all "3D hardprint" tasks, with formats for storing and viewing with a 3D web browser before printing. Advocates claim that the adoption of VRML would make RP more accessible globally. VRML 1.0 (http://vrml.wired.com/vrml.tech/vrml10-3.html) is based on facets, so it accommodates STL files as well as accommodating AutoCAD DXF and parts of IGES, among others.
Some RP research, for example, by Baily at the San Diego Supercomputer Center, deals with "telemanufacturing" issues (http://www.sdsc.edu/EnablingTech/Visualization/TMF/tmf_intro.html).
VRML will work well for describing the network-based objects in a 3D scene involving interaction, animation, or simulation, because VRML is a direct extension of interactive computer graphics. True network interaction and seamlessness will ultimately require Java-like concepts. VRML today provides a geometry-viewing capability but has not addressed engineering needs such as the creation of very complex geometry and the ability to use it in other analyses. (Future versions of VRML are expected to include NURBS, but today, such geometry creates a heavy processing load.) This is where STEP and other engineering network projects, like National Industrial Information Infrastructure Protocols (http://www.niiip.org/) or Computer-Aided Manufacturing Network (CAMnet) (http://ce-toolkit.crd.ge.com/ camnet/conops/conops_5.html) in the United States play an important role for engineering and manufacturing.
The engineering and manufacturing applications segment of RP will not be the major segment of the future RP market, and not necessarily the primary technology base for the mass market. In the past two decades, much of the innovative computer technology (PCs, RISC architectures, small high-density disks) and interfaces (Xerox PARC, Apple) that made computer technology accessible by the masses evolved from needs at the grass roots (even computer games), not from the needs of large mainframe operations. The same will be true for future 3D Fax technology -- it will have to be stand-alone, desktop, cheap, and universal.
Future RP systems for engineering and manufacturing applications will be specialized and at the cutting edge of processing sophistication, because these systems will replace existing manufacturing machines that make functional parts.
Duplicating CAD geometry manipulating functions in SFF machines preserves the functional independence of the machines from the CAD workstations generating the input data. Model manipulating operations that deal with SFF machine-specific functions, such as orientation, scaling, nesting, compensation, and slicing, need to be dealt with locally by an operator who understands the idiosyncrasies of the SFF process and the properties of the raw material. If, for example, a prototyped part warps or shrinks more than anticipated due to an unforeseen processing imperfection, the operator must have the option to compensate locally and make another run without having to go back to the CAD environment. The need to understand in detail the processing and material properties is even more important when producing functional parts (metals, ceramics, etc.).
If changes in the original design need to be iterated with a series of interim prototypes, then ideally, such incremental changes should retain as much of the originally processed data as possible.
As the RP market ultimately subdivides into focused segments, that portion dealing with producing form parts for viewing should achieve totally automated operation.