During the last three years we have extensively studied the problem of getting designs from designers to fabricators. Many parts were designed by the students working on this project as well as by students in several classes tought at Berkeley and elsewhere. The designs ranged from simple brackets and mechanical test parts to sophisticated housings with hinges for a variety of novel consumer electronics products and to complex, artistic, free-form shapes. Most of the designers involved were sitting for the first time in front of any kind of CAD system to define a custom-designed part. The parts were then built in ABS plastic on our in-house Fused-Deposition Modeling machine (FDM) or in aluminum on our 3-axis milling machine, or they were sent out for fabrication by local service shops, such as Metalcast or Plynetics, to be fabricated by a variety of other fabrication methods, including Stereolithography (SLA), Selected Laser Sintering (SLS), or injection molding. These studies have given us -- the investigators on this grant as well as the many students who participated in these experiments -- a good understanding of the problem faced by novice designers of mechanical parts and of what it takes to transfer their designs to a variety of different fabricators. This brought about significant changes in our recommendations for the preferred interchange format that should be used in this context of rapid prototyping. This will be described in detail below.
More general and also more complex digital interchange formats have been used with SFF, and most commercial CAD tools have their own preferred interchange format. Frequently used formats are ACIS, Pro-Engineer, or IGES. Unfortunately, these formats all have different semantics and different philosophies as to how a mechanical part should be represented. In many cases, the part description is not so much in the form of a terse description for the purpose of transmitting a part, but more or less a complete dump of the internal data structures that described the part during its design process. Whenever a part is converted from one description to a different one, some information, and often some accuracy, is lost. This process is irreversible; converting back to the original format will not restore the full original description. Paul Jacobs, director of R&D at 3D Systems, the manufacturers of the first stereolithography machines, writes that using an IGES specification as input usually requires extra work to get it ready for production, and that furthermore, IGES cannot always adequately and unambiguously define solids [JAC].
The desire for a better, vendor-independent exchange format has existed for a long time. Under the guidance of the National Institute of Standards and Technology (NIST), a corresponding development effort has been under way for many years. STEP is supposed to be the answer to the interchange needs in may different application domains. To make the format not too unwieldy by serving too many fields, STEP defines a language framework within which each application domain specifies their own set of exchange primitives. On first encounter, the whole system looks rather daunting, and parts of it are still under development. According to more than one presentation by David Ferguson of the Boeing Company at the last few SIAM Conferences on Geometric Design, even STEP has not solved their problem of transferring part descriptions without loss from one branch of Boeing to another one.
This state of affairs prompted us to propose another approach to the whole part exchange dilemma and to take as inspiration the EDIF format for the exchange of electronic designs [EDIF]. This format has its roots in CIF, the Caltech Intermediate Form [CIF], developed in the late 1970s for the purpose of giving the academic community and other novices in the field of VLSI design access to integrated circuit fabrication capabilities. CIF captured in a very simple and succinct manner the bare essentials needed to describe the few mask layers needed for MOS (metal-oxide-silicon) IC (integrated circuit) fabrication processes. During the early 1980s CIF became the lingua franca on the Internet through which first the academic institutions, and later also many industries, exchanged their designs of integrated circuit layouts. The rapid growth of the design domain of ICs and of the printed circuit boards and cabinets that combined many ICs into large electronic sytems soon outgrew the capabilities of CIF, and EDIF 1.0 was developed at UC Berkeley as a somewhat more structured and more extensible format that could be extended to an ever wider field of application. By 1999, this exchange format has evolved to EDIF version 4 0 0, its specification takes hundreds of pages, and a company has been brought into existence to maintain, enhance, and market EDIF.
The vision that fueled our proposal was to launch a similar effort for the description and exchange of mechanical parts. Since the format was aimed at the description of the shapes of solids, we chose the name SIF -- Solids Interchange Format. Our proposal and initial research direction was to create a language that would correct the many things that were found to be "wrong" with STL by the many people we talked to at conferences and at the three NSF workshops held between 1994 and 1996.
As a starting point, we created a set of specifications for SIF with the following general characteristics: SIF should capture the shapes of feasible solid models as a boundary representation, in a process-independent form, without pre-defined tessellation. It should be able to capture spheres and cylinders exactly. It should do all this in a terse, non-redundant way. This was to be achieved by explicit sharing and reuse of vertices by all the polygons or patches that would be connected to it. Multiple instantiations of pieces of geometry in different positions and orientations could further reduce the description length and guarantee that surfaces that subdivide two different materials are indeed a single boundary and that there are no cracks between them, as may happen when the surfaces of the two materials are described individually.
At that time, we further assumed that SIF should also allow a designer to transmit some explicit intent information, such as the topology of individual parts, the nesting of components in an assembly, the desired rigidity of any component, or the tolerances on its surfaces -- either to directly guide the machining operations or to help select an appropriate SFF process. Of course, we wanted to keep the format extensible to allow the addition of new semantic concepts, e.g., material properties, which may then be ignored by older tools.
Prompted by the workshop on "Advanced Information Infrastructure for Solid Freeform Manufacturing" at Stanford on Feb. 5-6, 1997, we also gave some thought as to how the language might be enhanced at a time when the solid freeform fabrication techniques would be able to handle mixtures of many different materials, density gradients, and varying surface colors. In the most extreme projection, 3D volume data in the form of a fine-grained 3-dimensional array of volume elements (voxels) may need to be converted directly into a solid model in which some material density corresponds to the "grey-value" in each voxel. A possible solution would allow SIF to include 3D voxel arrays, analogous to the way the PostSript Language allows the inclusion of 2D raster data in addition to traditional geometrical elements such as lines and polygons. Our original conceptual design of SIF thus was broad enough to be readily extensible to applications that may not materialize until five or ten years from now.
A) A designer has created some complex free-form shape and wants to send it to any suitable SFF machine for fabrication; the designer does not know and does not care how these machines operate.
B) A novice designer tries to define a part to be made on a 3-axis milling machine. It turns out that the designer must have at least some conceptual understanding of how a milling machine operates in order to be able to specify a machinable part.
C) A designer who is thoroughly familiar with the SFF machine that s/he is targeting wants to get the most out of the capabilities of that machine and achieve a special effect such as producing a thin-walled, hollow or loosely filled model. Rather than interfacing at the part description level, that designer wants to send the geometry of the individual layers (slices) by which the part will be built to the machine.
The explicit information content that needs to be transmitted in the three cases changes accordingly:
In Case A), a simple boundary representation will suffice. This role will be served by SIF, or more precisely by the "SIF_SFF" format.
In Case B), it would be wasteful to discard the implicit or explicit knowledge that the designer used to express the way that the part could or should be made. In the case of a 3-axis milling machine, the desiger typically thinks in terms of holes and pockets that need to be removed from the original stock. These "features" should become part of the vocabulary of the exchange format. By explicitly passing these features to the fabrication side, the task of process planning can be simplified considerably, since many of the conceptual decisions about the access direction for a particular feature have already been worked out by the designer. To satisfy this need, we decided to create a special dialect of SIF, called "SIF_DSG", to capture such "Destructive Solid Geometry" in the context of 3-axis milling. The main enhancement over ordinary SIF is that this format understands the notion of several features -- in particular, "pockets" that can be milled on a 3-axis milling machine. These pockets are described in terms of a 2D contour in a reference plane and by a depth, or possibly a more structured, curved bottom surface.
Case C) takes the designer another step closer to the actual fabrication process. Many of the fabrication parameters of the SFF machine (e.g., layer thickness), or the semantic form by which the machine represents the individual layers (contours versus filled raster), must now be taken into account explicitly. Obviously, the exchange format needs to transmit the necessary parameter values. We have developed yet another dialect "L_SIF" (layered SIF) to represent a solid part as a collection of horizontal slices. Basically, these slices are specified by 2D contours and by a layer thickness.
These two dialects, SIF_DSG and L_SIF, have been designed with the goal of immediate practical use and have been tested in the context of ongoing manufacturing experiments in the CyberCut environment. They have undergone few conceptual changes over the last couple of years and seem to serve their purpose quite well. Interestingly enough, a quite different story emerged in the development of SIF_SFF.
Our ambitious language design, while evoking positive comments from some academic sources, did not seem to find any real use. To a large degree, that was to be expected. We were well aware, even at the proposal stage of this project, that a new language on its own cannot be "sold" and that it would be necessary to create a certain infrastructure to go along with it. But while we were busy developing some of the key components of this infrastructure, we found that in most cases even within our group we did not much rely on this new exchange format. Most of the time we ended up submitting our test designs in STL form to commercial SFF machines. In the meantime, the language got richer -- and harder to implement and maintain. Ever more sophisticated designs prompted us to add new features to the language. Planning ahead to handle assemblies with movable parts added several new hierarchical layers beyond the uniform "lumps" of one and the same material. Multiple lumps of different materials could be fused together into rigid "bodies;" these rigid parts could in turn be assembled into "constellations;" and loose groups of such constellations could be submitted as one fabrication job, with the explicit understanding that the individual constellations in this group could be rearranged as long as they did not interfere with one another. The SIF_SFF langauge was also provided with constructs to capture the topology of the parts, as one aspect of "designer intent."
But -- not surprisingly -- SFF machines do not care about designer intent! They just produced the part specified by the geometry, regardless of the intended or specified topology. It finally occured to us that what we had developed was an interchange format to transmit a part design among designers -- not from a designer to a machine or to an (ideally) fully automatic fabrication process. Gradually we had lost our analogy with CIF, the lowest level at which an integrated circuit layout could be sent to a manufacturer. SIF_SFF 1.0 had moved to higher levels, more closely in analogy with the "functional" or "logic" levels of integrated circuit descriptions.
In 1999 we started to put our efforts into the proper domains. Our efforts in developing a high-level language were showing very fruitful results in the development of SLIDE, a Scene Language for Interactive Dynamic Environments, which is now being used in our introductory graphics course. We realized that this language also had much potential as the basis for an interesting CAD tool that could combine powerful procedural elements with direct interactive manipulation and parameter adjustments via sliders.
Once we had isolated our desires for high-level designer constructs, we could step back and analyze what really was needed in an interchange format that was not meant for human interference. The KISS (Keep it simple, stupid!) principle was applied heavily, and the language was trimmed down to the constructs that were absolutely essential, while we were trying to fix those aspects of STL that were wrong in a fundamental way.
The salient difference with respect to STL is the enforced complete sharing of vertices. The coordinates of any particular vertex in the shell representing the boundary of a piece of solid material get transmitted only once. All triangles that touch a particular vertex must reference this vertex explicitly. The main purpose of this requirement is not, as originally thought, a reduction in description length (because every such vertex with its coordinates is transmitted only once rather than an average of six times) -- rather it is a forcing function to make sure that the shell description is as clean and as unambiguous as it can possibly be. Creating such a description may be seen as an extra burden on the designer. However, we are convinced that in the long run this will have important payoffs. Bad descriptions need no longer be cleaned up by the fabricators who, in doing so, must guess the original intent and judge what modifications might be acceptable to the designer.
Instead, the necessary cleanup is done at the design end, where emerging ambiguities are resolved most naturally, and where sensible trade-offs can be made when potential manufacturability problems are predicted by the checking and verification tools. This is one of the important lessons that can be drawn from the VLSI CAD revolution. It is the designer's responsibility to ship only part descriptions that meet a set of design rules, which are formulated so as to guarantee that parts that pass all checks can indeed be fabricated. In return, the fabricators guarantee that such parts will be fabricated properly, possibly in a fully automated way, and will then meet certain predictable and justifiable expectaions (e.g., with respect to strength or dimensional tolerances).
In the mechanical world, this approach has long been known as "Design for Manufacturability." Its main advantage is that it avoids the "Request for Clarification" delays, and that it leads to the final product with fewer iterations and thus results in a shorter time to market.
The latest versions of our languages and in the accompanying support tools follow this philosophy, and encourage the designer by any means possible to bring the designs to a state of maturity that should then lead to a relatively straight-forward implementation. This may involve an extra amount of checking and/or simulation on the designer's side, but the additional time invested is well worth the resulting reduction in fabrication problems.
The faces in the boundary representation have been restricted to triangles to avoid problems and ambiguities with potentially non-planar facets. The vertices in each triangle must be referenced in counter clockwise manner when seen from the outside of the solid; this gives the shell an unambiguous orientation and clearly defines what part is inside and outside the shell respectively. These shells will further obey the Euler relation:
#_vertices + #_faces + 2*#_handles (=genus) = #_edges + 2
as they must also form a single, connected component. The genus of a boundary can thus be determined by simple counting.
To describe a hollow sphere, we obviously need two (concentric) shells. Originally we planned to capture the intended topology by forcing the description to include the description of the inner shell within the syntactic boundaries of the description of the outer shell. But inconsistencies can then arise if the inner shell is not fully, or not at all, contained within the outer shell. What should the SFF fabrication machine do in this case ? Will it have some kind of checker to detect this inconsistency? Probably not. And if such a checker tool is indeed available, then it should be run by the designer before submitting a design! Assuming an automated implementation process, these topology specifications serve no purpose and thus should be eliminated from the low-level exchange format.
Hollow sphere = (difference Outer_shell Inner_shell )
SIF_SFF 2.0 accepts all three types of classical Boolean operations:
(union A B C ... )
(intersection A B C ... )
(difference A B C D ... )
For convenience, these operators all take multiple operands. For the first two the semantics is obvious; for the difference operator the first operand is positive and all others are subtracted from it. Thus a ball with multiple cavities can readily be described with a single difference operator.
Conceptually, this avoids all inconsistencies and pushes any ambiguities to the domain of geometry. If the inner shell defining the cavity gets too close to the outer shell, or even penetrates it, one will simply obtain a genus-zero object akin to a fishbowl. The use of Boolean operations also has the advantage, that if one wants to drill a hole through a complex object, such as a solid model of a brain, or if one wants to add a raised feature onto the surface of a curved object, there is no need to determine a clean boundary representation before the design description can be sent for fabrication.
One may ask whether this approach just puts the burden on the fabricators to resolve this potentially very difficult problem of determining the resulting boundary description? It does, but only in a very limited way. First, on a milling machine, drilling a hole is a very simple and natural operation, and will perform the desired difference operation in a natural way, generating the final B-rep implicitly. In the domain of SFF, the various components of a Boolean expression can be sliced individually, and the Boolean operations are then resolved individually in each 2D slice -- a much more tractable problem! By pushing the task of calculating the locus of the geometrical intersection of two complex surfaces to the final fabrication step, the difficulties associated with the exact representation of this locus can be minimized, since the locus need only be determined numerically to within the precision of the fabrication process -- if at all.
However, the reality of the situation is that fabricators do not seem to be ready in the near future to accept such descriptions directly as a binding interchange format. Many would rather receive the part specification in the particular format of one of the commercial CAD tools (e.g., Pro-E) and would then tessellate and save the part description with the appropriate fineness for the chosen fabrication process. This is, of course, totally contrary to the idea of an unambiguous part description that could be sent to a fabrication machine without further human intervention. Since our own part descriptions were often produced with CAD tools that were not available at the fabricator's site, we ended up tessellating our designs ourselves before we sent them -- but not before we had informed ourselves as to how many triangles total would be considered reasonable for a particular machine.
The key problem with curved surfaces, of course, goes deeper than just agreeing on the particular way in which the control parameters for B-splines and NURBS should be transmitted. The main problem lies in creating perfect water-tight surfaces when curved surfaces and trimmed patches are involved. Trying to properly represent the edge where two curved surfaces intersect has been an open-ended problem in CAD for more than two decades. The calculated intersection curve in 3D is typically only an approximation of the real locus of intersection. The projections of that space curve onto the two curved surfaces that generated the intersection curve, with the goal to produce the required trim curves for the two patches, involves further approximations. The tessellation of the two trimmed patches may then create disjoint vertices and trim edges and leave a crack along the desired curved edge in the boundary representation. This crack can be closed, after the patches have been properly triangulated and neighboring vertices on the two shores have been merged into a compromise position. However, it seems impossible to describe such geometrical configuration in an explicit way at the level of the trimmed spline patches.
Because we wanted the new exchange format to adhere religiously to the principle of water-tight shells, we are not prepared at this point to define a way to incorporate trimmed patches into the SIF_SFF 2.0 interchange format. Giving up trimmed patches as an unreliable and ambiguous construct essentially forced us to implement Boolean operations. These are the operations that produce trimmed patches in the first place, and such constructs must somehow be transmitted from the designers to the fabricators. Since these operations often lead to approximations, it seems desirable to make the approximation only once, at the time when the tolerances of the fabrication process are known. However, the Booleans in the exchange format only take closed shells as operands, whereas the trimmed patches in most CAD tools work on individual (NURBS) patches. Thus the SIF_SFF 2.0 Booleans are not a complete solution to this long-standing problem of solid modeling.
A possible solution, which may actually solve the most pressing needs for curved surfaces, is to allow a couple of curved primitive shells in the Boolean expressions. Allowing parameterized expressions for closed cylindrical and spherical shells could readily provide the "exact" specifications for the cylindrical holes required for bearings or the balls and cavities for pivot joints. The fabricators would have to agree to have a corresponding implementation of these constructs that comes as close to the ideal as their fabrication process can achieve. These geometrical constructs would be naturally merged with other part geometries through the Boolean operations described above. This issue is still under investigation, and the current implementation of SIF_SFF 2.0 does not contain these curved constructs.
However, there should be no conceptual problem if closed shells are instanced as a whole. Thus a completly closed cog of a gear wheel could be defined and then placed thirty times around a wheel hub with a union operator. Minor numerical errors arising from the evaluation of the specified placement transformations do not matter, since those shells do not share any vertices with other shells. All such placements should be made robust to such numerical errors and to the tolerances of the fabrication method with an appropriate overlap between parts that are supposed to form a single rigid lump. However, for simplicity's sake, we will delay the introduction of instantiations and transformations until we perceive a real demand for them.
B-splines and NURBS are, of course, also procedural constructs. From a given set of control points, through a well understood (one hopes) procedure all points on the surfaces can be computed. Well accepted solutions exist to calculate suitable approximations for the purpose of fabrication, and others for rendering and visualization purposes.
With this in mind, it might be tempting to ask for other powerful constructs such as "sweeps of a specified profile along a given space curve." This is certainly a very desirable primitive for the designer. However, the field of geometric modeling is not at a stage where such constructs have been universally accepted. There is no standardized description that has been widely accepted; and it has not been defined what are acceptable solutions to approximate implementations for fabrication, or what semantic interpretation should be used when sweeps locally or globally self-intersect. Thus the uncertainties associated with such constructs must be resolved on the designer side. Within the particular CAD environment where such constructs are being made available, it can be determined most easily what the net result is -- and correct it if necessary. The result should then be turned into a lower-level, unambiguous description that can be transmitted without raising any uncertainties about the final outcome.
However, a promising trend emerges in the form of subdivision surfaces. Invented more than a decade ago, these recursive constructions have become truly popular in computer graphics in the last few years and have been used to describe the complex free-form shapes of animals or human actors. Subdivision surfaces, so far, have been largely ignored in the domain of mechanical CAD. Their potential power in this domain is that they allow to specify parts of arbitrary topology and geometry in a completely water-tight manner and at rather low expense. The description is based on a coarse polyhedral approximation with annotations that specify how the shape should be refined to arbitrarily fine precision. Some parts of the surface may be kept completely flat, while others approach a perfectly cylindrical segment. The actual description at any level of refinement remains perfectly water-tight. We plan to do more research in this very promising area.
In SIF_SFF 2.0, surface properties can be associated with shells or sets of triangles within a shell. The set of surface properties is extensible, but the obvious first uses are in specifying surface color or finishing quality. When shells intersect in Boolean operation, the individual surface pieces keep the properties from the shell that generated them. Thus if a cylinder is removed from a complex part, the part overall may have a relatively crude surface finish, but the cylindrical hole may be given a very fine finish so that it can serve as a bearing; this can be achieved by simply giving the cylindrical shell a corresponding specification on surface finish.
Some ambiguities may arise if shells with different surface specifications intersect with coplanar faces. Ideally, the designer should notice such an ambiguity, and clean up the part description. In practice, such a conflicting specification may indicate that the designer does not care which of the two surface properties are applied in the area of overlap. The parser of SIF_SFF 2.0 will retain the latest specification encountered, i.e., will override earlier specifications when a newer one is encountered for a particular piece of surface.
Volume properties are associated with complete shells. Shells that are being subtracted, i.e., cavities, obviously may carry specifications, but they do not affect any region of the finished part. In the case of the Boolean union operator, the same kind of conflicts may arise as discussed above for coplanar surface pieces. These contradictions are resolved in the same manner: the later specification will override previous ones.
Units must be specified at the start of the file. The current version supports inches or millimeters. (We originally had a default units setting, but after the recently discovered error with the lost Mars satellite, we reconsidered our position and made the units specification mandatory.)
On the other hand, specification of a "desired_accuracy" for the part is optional. This statement specifies a global error tolerance for manufacturing, indicating to the manufacturer what deviations from the ideal geometry described the designer is willing to accept when the part is physically realized. It will also serve as important input to our Manufacturing Analysis Service so that it can advise the user/designer about appropriate manufacturing technologies.
For some time we considered the inclusion of a "precision" statement that would indicate the maximum amount by which the designer believes that the values specified in the file may differ from the ideal geometry. Such numerical rounding errors are inevitable when we allow arbitrary transformations of the instances of a piece of geometry. The precision information would then be useful during vertex merging and for intelligent crack closing. However, now that we insist on topologically consistent closed shells, vertex merging is no longer necessary, and the precision statement has become superfluous.
Currently the only valid surface primitive in SIF_SFF 2.0 is the triangle. It would be easy to add triangle strips, triangle fans, and arrays of triangles to the language in the future. These types of constructs would make it possible to transmit descriptions more compactly. For the moment it is more important to keep the language scaled down, so that it does not deter vendors from adopting it because it might take too much effort to implement the code to read it.
All values in SIF_SFF 2.0 are represented in the same form as ANSI C floating point values. We discussed forcing all modeling tools to pick an integer grid using a global units flag and then writing all values as integers on that grid. This idea has the benefit of being totally unambiguous and forcing the designer to actively consider the precision that they need for a given part. But on further consideration, we felt that this extra hassle might prevent many users from adopting the standard. It is also true that most geometric operations performed on the parts sent to a fabricator, such as pre-scaling to compensate for shrinkage or part placement in the build cavity, use floating point operations. Thus any perfect integers shipped across the interface would be lost as soon as any of these transformations are applied to the CAD model.
The CyberCut group has been working towards making a complete feature recognizer and macroplanner for the geometries generated by SLIDE, so that those shapes that are compatible with the access and fixturing constraints of a 3-axis milling machine, could indeed be decomposed into the 2.5-dimensional features needed for that manufacturing process.
The other insight that has prompted us to switch to SIF_SFF 2.0 is our new focus on making SIF simple enough so that manufacturers of SFF machines can readily implement their own SIF interpreters. SIF_SFF 1.0 was too complex a language to be accepted by the manufacturers. We were originally inspired by the PostScript language, but then realized that most of the PostScript interpreters are written (and sold) by Adobe. This model may be less applicable in the domain of SFF machines, where new processes are still being invented every year, and where many of these processes have quite different needs for the form in which they need to extract detail geometry from the overall boundary representation. The most complex -- and as yet untested -- part of SIF_SFF 2.0 are the Boolean operations. However, for all the layered processes these operations can be reduced to two dimensions, and for that problem the routines available, for instance, in OpenGL can do the work. As part of our follow-on NSF grant: "MOSIS++, A Distibuted Manufacturing Resource for Research, Education and Industrial-Integration," we will test this latest version of our interchange format and of our thinking.
The emergence of the Web is changing the potential client community for rapid part prototyping. We are specifically trying to encourage users from many different applications domains who have no previous experience with part fabrication at all to use the emerging distributed design and fabrication environment. Design tools and fabrication planning tools that want to cater to this new breed of users will have to offer an interface that is different from that of the traditional heavy-weight CAD tools offered, for instance, by ComputerVision or AutoCAD during the last two decades. We want to provide tools that are much more light-weight and user-friendly, and which can readily run on a "home computer." In addition, we want to make these tools more robust against misuse, and more proactive in catching and correcting possible design rule violations, so that the part descriptions that emerge have a high chance of passing through the fabrication process without the need for any redesign by an experienced designer on the shop floor.
To increase the rate of successful designs when this system is used by "naive" designers who have not been trained in a machine shop, we have provided this tool with a design feature checker that performs a real-time check of the emerging design and catches potential design rule violations as they are being made. For instance, it provides instant notification of features that are too narrow or too deep for the reach of the available milling tools. Another type of rule is based on a comparison between predictions of workpiece deflection and the accuracy of the manufacturing process, specifically machining. In machining, "features" are typically created by removing substantial volumes of material which may result in relatively large forces. As a feature gets closer to the edge of the workpiece, its wall thickness decreases and the workpiece deflections increase. These deflections are regarded as negligible until they are of the same order as the machining tolerances. At this point, the thin-walled feature affects the overall accuracy of the final part, and the designer needs to be advised to alter his/her design.
Implemented in JAVA, the design feature checker is platform-independent and maintains the benefits of object-oriented programming. Despite its current limited capabilities, this checker has proven to be a valuable tool to offer with SIF_DSG. Already, several courses at U.C. Berkeley as well as groups at UIUC have successfully used it in conjunction with CyberCut to produce parts for class projects and concept demonstrations. WebCAD and its feature checker have provided designers with valuable feedback and increased their understanding of typical manufacturing constraints.
The WebCAD tool provided a thorough testing ground for SIF_DSG. This tool has been used in several classes taught at Berkeley during the last two years. It was also tested by researchers at a few other institutions. These experiences confirmed our belief that we need more than one dialect of SIF to serve various application domains optimally. The various dialects allow a variety of extra semantic constructs that capture important fabrication information that the designers may have worked out based on their understanding of the targeted manufacturing process, and which should be preserved when the design is sent across the standardized interface.
The main tool needed here is a robust slicing tool that cuts the given boundary representation into the appropriate layers, and also some tools to make offest surfaces for the computation of the inner boundaries of shelled parts. We have finished the development of an efficient slicing tool and have a couple of offset surface tools under construction. Experiments are in progress to find out what else is needed to give more advanced designers the means to get the most out of these layered SFF fabrication processes.
This format captures the slice geometry, including unevaluated booleans passed along from the original input. Our slicer tool writes to this manufacturer-independent format. We have written the parser for L_SIF and two converter programs. One takes L_SIF input containing booleans and resolves the booleans, outputing L_SIF containing simple nested contours, as an aid to manufacturers who do not want to resolve booleans themselves. The second converter takes L_SIF input and outputs the SSL slice format accepted by the QuickSlice software the FDM machines manufactured by Stratasys. We plan to explore these lower level interfaces for a few different SFF machines under the NSF CADRE MOSIS++ grant that started in the Fall of 1999.
The different applications and operations require different levels of complexity and cross referencing in the data structures that implement them. Some applications, like simply viewing a shape graphically, may not require any topological linking at all, where as an analyzing tool like our slicer program may require a full radial-edged data structure in order to perform its task reliably and efficiently. Thus we have developed more than one efficient geometric representation with different amounts of linking between the various primitives, as well as robust implementations of the necessary geometric algorithms operating on them.
The first is a simple data structure useful for simple rendering and conversion of files. This data structure is designed to allow fast construction from a file description. This is desirable for putting images up to the screen quickly to give the user immediate feedback. Another advantage of this simple data structure is that it is easy to test out new constructs that might be added to SIF. We have used this data structure to build viewers for SIF_SFF 1.0 and STL files. We have also used it to build converters between selected pairs of the following interchange formats: SIF_SFF, SIF_DSG, STL, ACIS, and Berkeley UniGrafix. Fast interactive visualization of booleans still needs to be implemented and will require a more elaborate data structure; we are in the process of developing a prototype based on convex difference aggregates [CDA].
For more complicated tasks, such as analyzing the 2-manifoldness of a b-rep, we have defined and implemented a new compact topological data structure called LEDS (Loop Edge Data Structure). We have also developed a framework for building this data structure efficiently even when it contains more information than can fit into available memory. We have chosen an approach in which all random memory accesses during construction are re-ordered into sequential accesses grouped with corresponding hash table partitions that fit in memory. This approach uses operating system facilities for memory mapping to increase page swapping efficiency. This allows us to process geometry descriptions with millions of polygons with reasonable efficiency.
For more complex solid modeling operations in the context of the SLIDE front-end for designing SFF parts, we have also implemented a fully connected quad-edge data structure. This data structure is better suited to dynamic topological operations than LEDS. Current operations that make use of the quad-edge data structure include: hierarchical vertex merging, complicated polygon tesselation, Delaunay triangulations, and simple subdivision algorithms for creating smooth closed surfaces. Future operations might include interactive editing, offset surfaces, minimum feature size calculations, and 3D CSG operations.
The infrastructure described above has been implemented in an object-oriented frame work. High-level superclasses define the interface that must be supported by any underlying data structure. These super classes will also implement high-level operations common to all data structures by making calls to the shared geometry interface. An example of this would be a rendering pass where a group will call the render statement on all of the components that comprise it. The actual implementation of the render procedure on these components will depend upon which data structure is being used in the application. The use of this interface will allow reuse of these modules throughout our system, thus reducing the amount of programming work. In addition, when improvements are made to a single module, then all applications that use it will share the benefit with a minimum of extra effort.
In Fall of 1999 the machine has been used intensively in two classes. In ME221/BA296, "Intelligent Manufacturing Systems: Technology and Management" the students combined various electronic consumer products in innovative ways.
In ME 290, "New Product Development" the FDM machine was used in an ingenious way to make a "Contact Compact," a self-contained portable contact lens case that can hold a replaceable saline and hand cleanser cartridge as well as an extra set of disposable lenses. It featured a hinged top with a mirror and a built-in light that is switched on and off automatically.
The "SIF + Cybercut" research has particular economic impact on the design and fabrication of new products for the consumer electronics industry, where time-to-market is critical. Our NSF/DARPA award is to create a prototypical set-up with the necessary tools, interchange formats, and implementation software, and then "hand it off to industry." We are driven by the following vision: "There are many designers `out there on the Internet' who want mechanical parts in a hurry. For such clients both at other Universities and in Industry, the goal is to quickly go from concepts to parts in analogy to the services provided by MOSIS (the Metal Oxide Semiconductor Implementation Service) for VLSI integrated circuits." However, in the domain of mechanical design, the link between conceptual design and implementation is not as well defined. Therefore, the parts must be designed with some basic understanding of the process by which they will be fabricated. This has led to the rethinking detailed above.
We believe that our research has helped to create a new conceptual foundation for this new paradigm of manufacturing.
[CIF] C. Mead and L. Conway, "The Caltech Intermediate Form for LSI Layout Description." In "Introductoin to VLSI Systems," pp 115-127. Addison Wesley, 1980.
[EDIF] EDIF Organization Home Page: www.edif.org/about.html
[JAC] P.F. Jacobs, "Rapid Prototyping and Manufacturing : Fundamentals of Stereolithography." Society of Manufacturing Engineers, Dearborn, MI, 1992.
S.A. McMains, "Rapid Prototyping of Solid Three Dimensional Parts," Master's Thesis, U.C. Berkeley, 1995. UCB Tech Report UCB/CSD-96-892. {Detailed descriptions, evaluations, and comparisons of different layered manufacturing (a.k.a. rapid prototyping) technologies.}
S.A. McMains, C.H. Séquin, and J. Smith, "Dealing with Data Imprecision, Design Tolerances, and Manufacturing Limitations in SIF," Measurements and Standards Issues in Rapid Prototyping, Oct 16-17, 1997, National Institute of Standards and Technology, Gaithersburg, MD. {Described the current state of the SIF interchange format and supporting infrastructure in general, and constructs for communicating data precision and tolerances in particular.}
C.H. Séquin, "Virtual Prototyping of Scherk-Collins Saddle Rings," Leonardo, Vol 30, No 2, pp 89-96, 1997. {Describes a parametrized generator for artistic geometrical shapes.}
P. Wright, C.H. Séquin, "CyberCut: A Networked Manufacturing Service," Int. Conf. on `Managing Enterprise Stakeholders, Engineering, Logistics and Achievement' UK, July 22, 1997. {Gives high-level view of the improvements needed in the interface between designers and manufacturers.}
C.H. Séquin, "Art, Math, and Computers: New Ways of Creating Pleasing Shapes," BRIDGES - Mathematical Connections in Art, Music, and Science; Conf. Proc., pp 1-10, Winfield KS, July 1998. {The use of rapid prototyping in the world of the arts.}
S.A. McMains and C.H. Séquin, "SIF: The Emerging Solids Interchange Format," Fifth SIAM Conference on Geometric Design, Nov 3-6, 1997, Nashville, TN. (No proceedings.) {Described the shortcomings of STL, the properties of SIF, and the analysis and implementation tools we were in the process of building.}
S.A. McMains, C.H. Séquin, and J. Smith, "SIF: A Solid Interchange Format for Rapid Prototyping," Proceedings of the 31st CIRP International Seminar on Manufacturing Systems, May 26-28, 1998. Also to appear in CIRP - Journal of Manufacturing Systems, Vol. 29, No. 1, 1999, and as Technical Paper PE99-117, Society of Manufacturing Engineers, Dearborn, MI, 1999. {Describes the philosophy behind the SIF format and our thinking on its specification at the half-way point in the project, including the introduction of a new dialect aimed at machining.}
R. Hillaire, L. Marchetti and P.K. Wright, "Geometry for Precision Manufacturing on an Open Architecture Machine Tool (MOSAIC-PC) Proceedings of the ASME Interna- tional Mechanical Engineering Congress and Exposition, MED-Vol.8, Anaheim CA., November 1998, pp. 605-610.
R.H. Crawford, J.J. Beaman, C. Cavello, J.D. Jackson, L.E. Weiss, and C.H. Séquin, "Solid Free-form Fabrication, a New Manufacturing Paradigm," IEEE Spectrum, Vol 36, No 2, pp 34-43, Feb. 1999. {Compares different fabrication methods for rapid prototyping.}
S. McMains and C.H. Séquin, "A Coherent Sweep Plane Slicer for Layered Manufacturing," Proceedings of the Fifth ACM Symposium on Solid Modeling and Applications, June 1999, p. 285. {Describes a robust, efficient, sweep-plane algorithm that exploits geometric and topological coherence to produce closely spaced slices needed for layered manufacturing from solid CAD model input.}
Jae Ho Kim, F.-C. Wang, C.H. Séquin, and P.K. Wright, "Design for Machining Over Internet", the Design Engineering Technical Conference (DETC) on Computer Integrated Engineering Paper Number DETC'99/DFM-8938. Las Vegas, Sept. 1999 Note: these Pro- ceedings are on CD-ROM thereby precluding page numbers. {Description of the evolution of the WebCAD tool}
G.Sun, F.-C. Wang, C.H. Séquin, and P.K. Wright, "Operation Decomposition for Free- form Surface Features", the Design Engineering Technical Conference (DETC) on Com- puter Integrated Engineering Paper Number DETC'99/DFM-8964. Las Vegas, Sept. 1999 Note: these Proceedings are on CD-ROM thereby precluding page numbers. {A crucial set of steps in the path from a freeform surface description to a tool path for 3-axis milling.}
C.H. Séquin and J. Smith, "Parameterized Procedural Synthesis of Artistic Geometry," Int. Journal of Shape Modeling, Vol 5, 1999. {Shows the use of SLIDE to generate abstract geometrical sculptures.}
F.-C. Wang, J. Plancarte, V. Fabbrizio, P.K. Wright and A. Kramer "Industrial Design to Rapid Mold Making for Accelerated TIme-to-Market of Consumer Electronic Prod- ucts", Proceedings of the ASME International Mechanical Engineering Congress and Exposition, Nashville TN., November 1999. {High-level view of the emerging design for manufacturing paradigm.}
V. Sundararajan and P.K.Wright, "Identification of Multiple Feature Representation by Volume Decomposition for 2.5 D Components", Accepted for the Transactions of the ASME, Journal of Manufacturing Science and Engineering, 2000. {Describes the macroplanner in the SIF-to-CyberCut pipeline}
The original project page for the SIF/CyberCut development group:
http://http.cs.berkeley.edu/~sequin/PROJ/sif.html
The complete description of the syntax and semantics of SIF_SFF Version
2.0:
http://www.cs.berkeley.edu/~ug/sif_2_0/SIF_SFF.shtml
Our sweep plane slicer, accepting SIF_SFF or STL input and outputing
L-SIF, exploits inter-slice coherence for efficient processing:
http://www.cs.berkeley.edu/~ug/sif_2_0/slicer.shtml#slicer
Our analyzer which program builds our topological data structure, LEDS,
to check that the SIF_SFF or STL input describes a valid, closed solid;
if not, it attempts limited clean-up in the form of vertex merging:
http://www.cs.berkeley.edu/~ug/sif_2_0/slicer.shtml#analyzer
Samples of test parts of different topologies, designed to test the
limits of our slicer:
http://www.cs.berkeley.edu/~ug/sif_2_0/slicer.shtml#slicetest
Parts designed in various courses at U.C. Berkeley:
http://kingkong.me.berkeley.edu/html/gallery/index.html
Parts made on our Fused Deposition Modeling Machine:
http://www.cs.berkeley.edu/~sequin/SFF/FDM_parts/fdmparts.html