Generating sample looks for geometric objects in a visual design language

Abstract

A major application of visualisation is to the design of structured objects such as buildings, machinery and electronic circuits, as in computer-aided design (CAD) systems. Complex designs are frequently parameterised so that they represent families of objects rather than single artifacts, and building them requires design environments that support both the concrete visualisation and manipulation of components, and the abstract specification of how they are related. CAD systems usually separate these two aspects, providing the abstract programming capability via a textual programming language grafted on to a 3D object editor and solid modeller.

A recently proposed design language merges these two activities by embedding representations of solid objects in a visual logic programming language. A practical issue that arises is how to automatically generate a “sample look”, a reasonable representation for a parameterised object which can be displayed during execution (assembly) of a design. We present a solution to this problem based on “factoring”, which separates the constraints on a solid object from its geometric properties.

Introduction

Computer-aided design (CAD) systems, used almost universally in industrial design, have their origins in the paper-based drafting and physical prototype modelling that they replaced [5]. Consequently, they feature highly sophisticated graphical editing capabilities for building and manipulating detailed 3D models of objects. As the requirements of industrial design have become more complex, CAD systems have evolved to include facilities for building parameterised designs, defining families rather than single objects. In simple cases, parameter values are specified via forms or files [21], but more complex parameterised designs require programming, usually in a variant of an existing programming language [6]. Hence there is a sharp divide between designing and coding, the two tasks being performed with very different tools, and, frequently, by different people.

To address this problem, CAD researchers have devised various notations for describing the structure of families of objects, resulting in design languages that unify the design and coding aspects of parameterised CAD systems [15], [17]. Since such languages are textual, however, they do not exploit the visual nature of the objects they specify and manipulate, moving the design process towards the programming end of the design/coding spectrum.

The developments in microprocessor technology that enabled the evolution of CAD systems, especially graphics capabilities, also encouraged programming language researchers to investigate the use of graphical representations in programming. A wide variety of visual programming languages has resulted [10], many capable of supplanting their textual counterparts in industrial settings, and providing significant advantages [22]. In an attempt to bring some of these advantages to design languages, Milicchio et al. recently introduced a diagrammatic interface to the functional design language PLaSM [14]. Although the resulting language, Visual PLaSM, may simplify the building of functions that generate parameterised geometric objects, like its textual counterpart, it does not incorporate visualisations of the objects, so is still focused on programming rather than design.

To alleviate the disconnect between design and programming, a visual design language, LSD (language for structured design), has been proposed, using visual language technology to provide programming capabilities [12]. In LSD, constituent components and the operations that relate them, are visually represented in designs, diagrams that specify how components are assembled into a structured object. When a design is executed, it assembles an instance of the family of objects it defines. Note that this instance may still be parameterised. Execution can be animated, providing a clear illustration of the semantics of the design.

Aspects of LSD explored to date include implementation issues, programming environment and debugging tools, automatic layout of design diagrams, the formalisation of design spaces, behaviour of structured objects, motion modelling, solid modelling, and solving higher level design problems via the declarative problem solving capabilities that LSD inherits from logic programming [2], [3].

A design in LSD is a collection of diagrams (cases) in which some elements are visual representations of logic program entities, while others are visual representations of design space objects and operations on them. For example, Fig. 1(a) shows an LSD design partial cog, consisting of two cases. In the partial cog design, the function cell +1 corresponds to a literal x=+1(y) and the implicit component partial cog corresponds to a literal partial_cog(y,z,w), where x,y,z and w are variables corresponding to the connections between icons. The icon labelled tooth is an explicit component representing an object in the design space; and the grey bands represent a bond operation which welds objects together in the design space. Fig. 1(b) shows a specification, and (c) the explicit component that is assembled when the specification is executed using the partial cog design.

Implicit components, such as the partial cog icons occurring in the first case of the partial cog design in Fig. 1(a) and the specification in (b), represent objects to be assembled during execution. An explicit component, on the other hand, represents an existing object, maintained in an associated solid modeller. A bond represents an operation that the solid modeller can apply to objects.

The semantics of LSD are illustrated in Fig. 2, which shows the execution steps that transform the specification in Fig. 1(b) to the explicit component in (c). First, an application of the replacement rule replaces the implicit component partial cog with a copy of the body of the first case of the partial cog design, as shown in Fig. 2(a), resulting in the diagram in (b) once “dangling” bonds are deleted. Execution of the function cell +1 leads to Fig. 2(c). Note that although function cells are normally subject to two logical rules (illustrated in the last two steps of this example), like Prolog, LSD has extra-logical rules for certain special cells. For example, a function cell +1, which, as noted above, represents a literal of the form x=+1(y), is equivalent to either x is y+1 or y is x−1 in Prolog, depending on which of x and y is bound. Another application of replacement and function cell evaluation yields the diagram in Fig. 2(d), in which there is a bond that can be executed since it connects two explicit components. Executing the bond yields Fig. 2(e). In the next step, the partial cog component is replaced, this time with the second case of the partial cog design, producing Fig. 2(f). The two identical, connected function cells 0 (constants) are merged into one, producing Fig. 2(g), and finally, this function cell, because it is not connected to anything, is deleted. Execution terminates, having assembled the explicit component in Fig. 2(h).

The reader is encouraged to consult [12] for a detailed description of LSD syntax and semantics, and [11] for a formalisation of the underlying logic.

Clearly, the concepts “explicit component” and “operation” can be formalised in LSD only to a limited extent, since the appearance and behaviour of a particular explicit component or operation depends on physical properties of the corresponding solid or design space operation, such as geometry. In practice, an LSD implementation would deal with the logic programming aspects of execution and rendering, but call on a solid modeller to handle the rendering of explicit components and operations, and to apply operations to components. By “solid modeller” we mean a solid modelling kernel extended with additional capabilities to provide services required by LSD, in the same way, for example, that Autodesk Inventor [1] extends the ACIS kernel [9], [19], and SolidWorks [18] or Bentley Systems’ MicroStation [4] extend the Parasolid kernel [16].

To define the interface between LSD and a solid modeller, a very general notion of design space was required, providing just enough detail to capture the essence of solids in logic. Accordingly, a formal model for characterising objects in a design space was proposed in [12]. This formalisation also defines the concept of operations on solids, and selective interfaces that allow solids to declare what operations can be applied to them. It is important to note that this formalisation characterises solids and operations only to the extent required by LSD, without addressing any of the practical details of solid modelling.

In our example, the tooth icon represents a design-space solid, several instances of which are introduced and welded together by the bonding operations during execution. Clearly, the solid represented by tooth must be parameterised, since, for example, instances are rotated during bonding as shown in Fig. 2(e), indicating that the orientation of the tooth solid is variable. If a solid is not parameterised, its representation in LSD can simply be a direct rendering. A parameterised solid, however, represents a family of fully specified solids, some member of which must be selected to provide a representation.

In the following, we investigate the problem of determining a “sample look” for a parameterised solid. In the process, we extend the design space formalism in [12] by adding a refined representation for solids called a “factoring”, which communicates solid modelling information that can be used to automatically compute a sample look. Factorings also facilitate other manipulations of solids, which we will briefly discuss, and present in detail in a later publication.