A framework for extendable freeform surface feature modelling

Computers in Industry 60 (2009) 35–47

Contents lists available at ScienceDirect

Computers in Industry journal homepage: www.elsevier.com/locate/compind

A framework for extendable freeform surface feature modelling Paulos J. Nyirenda *, Willem F. Bronsvoort Faculty of Electrical Engineering, Mathematics and Computer Science, Delft University of Technology, Mekelweg 4, NL2628 CD Delft, The Netherlands

A R T I C L E I N F O

A B S T R A C T

Article history: Received 21 January 2008 Received in revised form 31 July 2008 Accepted 7 September 2008

The need for more efficient freeform feature modelling cannot be overemphasized. Freeform shapes are applied in many areas, including automotive and aerospace industries. In these applications, precise design functions need to be reflected in the final product. This requires advanced freeform feature models that are extendable and that provide sophisticated, yet user-friendly facilities, such as user-defined freeform features, intuitive parameters and effective constraints to guarantee model consistency. This paper extends, in a new framework, two aspects of freeform surface feature modelling: design of features and design by features. Design of features includes creation of new user-defined freeform surface features and their management. This functionality is supported by the freeform feature library management system, which enables the user to create new feature class definitions. Design by features is supported by a new freeform surface feature model, which extends the usual two-level parametric model structure with a third, intermediate level, called the partially evaluated model. Its capability to explicitly capture feature interactions, and support for intuitive attachment of features and parameters in the model, enables the new feature model to be extendable with, for example, new parameters. Curve parameters enable intuitive shape manipulation according to declared constraints. A running example model is used to demonstrate design of features and design by features, which includes advanced model variation. ß 2008 Elsevier B.V. All rights reserved.

Keywords: User-defined freeform features Freeform surface feature model Curve parameters Constraints Model variation

1. Introduction The fast pace of technology, in response to the ever-growing requirements on the global marketplace, has considerably shortened product development cycles. Although many industrial products can be designed, analysed and manufactured using most current computer-aided design/engineering/manufacturing (CAD/ CAE/CAM) systems, detail design still poses several challenges. In particular, creating and editing complex freeform shapes, such as car body elements, remains a daunting task for the user of current CAD systems. It still requires a lot of work-arounds, e.g. controlpoint manipulation, more dependent on expediency than on principle. One major concern is that most current systems are built on architectures that are limited to customer demands, with little or no provision for extendibility. In particular, although most systems offer sets of standard pre-defined volume features, e.g. slots and pockets, and, possibly, some non-standard system-defined features, they lack in support for freeform surface features, in

* Corresponding author. E-mail addresses: [email protected] (P.J. Nyirenda), [email protected] (W.F. Bronsvoort). 0166-3615/$ – see front matter ß 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.compind.2008.09.008

particular user-defined ones [1]. Freeform surface features are quite different from freeform volume features, as also shown in the recently published state-of-the-art report on freeform features [2]. Freeform surface feature definitions formalised in terms of highlevel parameters and constraints will enable integration of design intent in freeform surface features. Without this, a CAD system will fail to fully capture the engineering significance in the shape of freeform surface features, pre-defined or user-defined. Feature modelling systems represent products using feature models. A feature model is made up of one or several features, each of which carries specific functional information. Virtually all current feature models reflect a dual structure [3]. By this structure, on the one hand, the systems deal with an unevaluated model containing individual instances of the feature definitions. On the other hand, they deal with an evaluated model comprising imprints of the feature instances on the model, which constitute a boundary representation of the final shape of the product. However, the dual structures run into difficulties when features interact [4]. In particular, the use of freeform features in the final shape is not adequately supported. This inhibits the effective use of numeric and curve parameters attached to the model boundary, besides the parameters intrinsic to the features themselves, e.g. intersection curves to directly edit the features of which they are intersections.

36

P.J. Nyirenda, W.F. Bronsvoort / Computers in Industry 60 (2009) 35–47

A final problem is the dependency of feature models on the model history [5]. Most current commercial feature modelling systems follow the parametric constraint-based paradigm. In these systems, part families, or classes of parts, can be characterised by a limited number of parameters. The design history, in the unevaluated model, has a major effect when editing the design. The cause of this is that the systems rely strongly on a history-based interpretation of the unevaluated model to maintain its evaluated model’s boundary representation. This dependency on the model history is undesirable, as it forces the user to reason in terms of a strict chronological feature creation order. In order to address these shortcomings, this paper presents a framework for extendable freeform surface feature modelling. The new framework offers facilities to create new user-defined features, and to extend existing feature definitions. Its underlying feature model is based on the three-level structure developed by Nyirenda and Bronsvoort [4]. It links the unevaluated and evaluated models using a partially evaluated model, which explicitly captures feature interactions, feature attachments, and both numeric and curve parameter attachments. The new framework uses dependency relations between the constituent features to evaluate the model shape, not the feature creation order. This paper demonstrates several new facilities for freeform surface feature modelling offered by the framework, namely: creation of new user-defined freeform surface feature definitions, feature instantiation and attachment, parameter attachment, and model variation. The rest of the paper is outlined as follows. Section 2 gives a short background on feature modelling. In Section 3, the framework functionality and system architecture are outlined, and the new facilities are further introduced. Section 4 presents feature class definition. In Section 5, feature model specification is described and demonstrated. In Section 6 feature model variation is demonstrated and, finally, the paper is concluded in Section 7. 2. Feature modelling Feature modelling is a design paradigm that has emerged as an alternative to traditional geometric modelling. In feature modelling, various types of features are offered as the basic engineering primitives for product design. The definition of a feature that seems generally accepted is that a feature is a representation of shape aspects of a product that are mappable to a generic shape and functionally significant for some product life-cycle phase [6]. Examples of commonly used of features are slots, holes, pockets and ribs. This section gives a short background on the feature modelling concept. It may be worth to note that some of the information is influenced by our conception of features. 2.1. Geometric modelling versus feature modelling Conventional CAD systems only provide the geometric shape of a product. The shape could be described using constructive solid geometry (CSG), boundary representation (BRep), or other schemas. The most prevalent is the BRep, because, unlike CSG models, it is evaluated and can also represent freeform surfaces. In the past two decades, geometric modelling systems have evolved into more powerful modelling systems embracing the feature concept. In an advanced feature modelling system, each feature has a well-defined meaning or semantics [5]. A feature model encapsulates information about the constituent features in an application-specific context. Thus, a feature can have a different meaning depending on the context it is used in [7]. For example, in product design it is appropriate to provide features whose shape corresponds to some specific function for the user of the product,

whereas in manufacturing process planning, features that correspond to a volume to be removed from some stock part to produce the product would be appropriate. This information constitutes functional information. By enabling the designer to perform modelling tasks at a higher level, feature modelling facilitates specification of many relevant aspects in a product model. However, most current feature modelling systems are still too tied to conventional geometric modelling techniques, e.g. with regard to dependency on model history, and do not effectively take functional information previously declared by the designer, e.g. model validity conditions, into account [7]. A major reason for these shortcomings is that the systems heavily rely on a BRep to specify feature models. The BRep cannot store high-level information vital to feature modelling, e.g. constraints. 2.2. Generic feature definitions Generic features can be described using the object-oriented concept of a feature class, which defines a template for all its instances. All the properties of a feature type are specified in the corresponding feature class. In order to be useful, a feature class should embody at least three different sets of properties: parameters, constraints and generic shape. Parameters are used to characterise the shape, e.g. height and radius. Constraints are conditions expressing the shape’s characteristics, often implied from the functional requirements. The generic shape constitutes the canonical form of the feature class in terms of geometric entities, e.g. points, curves and surfaces, and topological relations between the geometric entities. A feature class also includes a canonical shape construction method, which encapsulates one or several functions that specify how the shape is determined in terms of the parameters, constraints and geometric entities declared in the class. Parameterisation of freeform surface features is more difficult, compared to regular-shaped features, because of the increased degrees of freedom. 2.3. User-defined features Current feature modelling systems offer a set of pre-defined feature classes, which are defined at the time the system is built. Although some systems offer only standard features, e.g. slots, pockets and ribs for regular-shaped features and ridges and bumps for freeform features, nowadays many systems offer non-standard features as well, e.g. general protrusions and sweeps, both for regular-shaped and freeform features. In most commercial systems, these general protrusions and sweeps are often termed user-defined features. In such features, geometry is created topdown, e.g. vertices and edges result from face or shell definitions. Unfortunately, the vertices and edges so-created cannot be directly edited by the user; neither can the user edit the resulting feature through attaching new parameters to the elements. For this reason, such constructs are by no means real user-defined features. Using pre-defined features only with a large set of feature types is not practical, since an exhaustive enumeration is both infeasible and unmanageable. Research and industry efforts have attempted to define comprehensive sets of features for mechanical parts, e.g. using group technology, but found that due to the extremely wide variety of parts available, it is usually necessary to define new feature types, or classes. But basing new feature classes on procedural classes, e.g. sweep, protrusion and skinning, as in the current systems, does not address the above noted concerns. Consequently, the concept of user-defined feature remained a topic of research. A user-defined feature, also called a ‘‘feature

P.J. Nyirenda, W.F. Bronsvoort / Computers in Industry 60 (2009) 35–47

prototype’’, is a customised feature that is defined by a user. The definition of a user-defined feature is ‘‘a design process that creates the feature prototype and the instantiation of the prototype in a design process defines its usage’’ [8]. In design of features, the user is allowed to create new feature definitions, either (i) from scratch, (ii) by deriving from pre-defined features, or (iii) by deriving from other user-defined features. By supporting user-defined features, it is no longer necessary to create complete feature sets from the outset; a modelling system can be customised without the need to re-implement parts of it. 2.4. Feature models In product design, features models are built using the design by features technique. This technique enables the user to create a product model by instantiating feature classes from a library. Ideally, all the information relevant to design is captured in the model through the available feature instances and additional model parameters and constraints. The instantiation of a feature class requires specification of all the dimension and location parameters for the feature type, i.e. values are assigned to the parameters. The feature instance may then be added to the model, positioned in the model and, possibly, attached to other features. A feature attachment declares the coupling of specific faces, called attach faces, of the features being attached. Each feature instance has a concrete shape, called feature shape, evaluated from its generic shape description in the corresponding feature class. A feature shape has parameterised geometry called feature geometry, and topology called feature topology. Several properties can be introduced into feature models using parameters and constraints. For example, a constraint can be imposed on the relative topology of the feature on the model boundary, declaring that the feature remains internal to another feature [1]. Each property can be classified as either generic or specific. This allows the model to contain many instances of essentially the same feature definition. Feature shapes are stored in an unevaluated model, which is usually represented by a graph, e.g. a feature dependency graph (FDG) [5]. The FDG contains all the feature instances, attach relations and constraints. Besides, feature imprints are stored in the evaluated model, which is usually a BRep. From a functionality viewpoint, there should be a generic mapping between the design features and their imprints, because, whereas a designer typically interacts with the BRep, the modified design features are updated prior to model boundary re-evaluation. The design by features technique offers a set of editing operations for the feature model, e.g. for inserting, placing and attaching features in the model, for deleting features from the model, for modifying constraints, and for changing dimension values of a feature. Each edit operation triggers an automatic update of the geometry in the modified features, followed by the creation of the new BRep by boundary re-evaluation. In a semantic feature model [5] the model is specified in a declarative manner, and evaluated according to feature precedence defined by the dependencies, in the FDG, between the features. In contrast, most commercial systems depend on model history, which has a computational cost that is proportional to the size of the model history [9]. 2.5. Freeform surface feature modelling Features can be categorised, based on form, into regular-shaped and freeform features. Regular-shaped features have prismatic, cylindrical or spherical forms, e.g. pockets and slots. Freeform

37

features may be volume-based or surface-based, namely freeform volume features and freeform surface features, respectively [2]. Example freeform volume features include the usual regularshaped features, but instead with freeform faces, i.e. faces modelled by Non-Uniform Rational BSplines (NURBS) [10]. Whereas volume features are used to model (solid) parts [11], surface features are used to model sheet products [2]. Freeform surface feature shapes are, again, represented by NURBS, and examples of freeform surface features include bumps and ridges. This paper focuses on freeform surface features. The shape of a feature is described using parameters and constraints; the NURBS surface is a geometric representation, determined from the generic shape definition of the particular feature type. 3. Framework functionality and system architecture This section demonstrates the importance of an integrated framework by contrasting our new system architecture to that of current systems; commercial or academic. It should be noted that, although some of the functionality is not new, it is relevant to envisage how existing techniques and the new techniques introduced in this paper can be easily integrated in the architecture of our extendable framework. First of all, the functionality of our framework is introduced. We explain why it is able to support freeform surface feature modelling more effectively than traditional systems. Secondly, the overall architecture used to implement this functionality is presented. 3.1. Framework functionality The framework supports (i) a large feature domain, (ii) extendable generic feature definitions, (iii) management of freeform surface feature definitions, (iv) creating complex freeform surface feature models, and (v) advanced freeform surface feature model variation. 3.1.1. Large feature domain Three limitations can be identified with regard to the feature domain in current feature modelling systems. First, in most systems, ‘features’ are in fact only advanced shape macros. Although these macros manifest themselves in the graphical interfaces as features, only the resulting geometry is stored in the product model [7]. Second, most systems do not provide surface features. Although they can model complex surfaces, their shapes are still defined using low-level geometry, such as control points, weights and knot vectors for NURBS surfaces only. Third, if they do provide surface features, most systems support only relatively simple freeform shapes defined by, for example, freeform extruded curves. In the new framework, freeform surface features are provided as high-level parametric, constraint-based definitions, which enable defining more complex freeform shapes. 3.1.2. Extendable generic feature definitions The need to support user-defined features has long been a topic of research [8]. However, this concept has not yet been adequately addressed in freeform surface feature modelling. One may attribute this to lack of a formal definition for freeform surface features. The definition of a feature requires the specification of all parameters and constraints that fully represent the feature. Parameters may be numeric and/or curve parameters. Constraints can be parameter constraints or shape constraints. A parameter

38

P.J. Nyirenda, W.F. Bronsvoort / Computers in Industry 60 (2009) 35–47

constraint is a restraint on a parameter, e.g. a value constraint used to set the allowable range for the value of the parameter. A shape constraint applies to the feature shape, e.g. a curvature constraint used to declare the allowable range for curvature in the shape. However, not all possible parameter types are available, or even important, to certain feature types. Therefore, we introduce the notion of generic abstract features [1], which refers to features that cannot be instantiated until the required minimum set of parameters has been specified. In design of features, we use this object-oriented concept to create new feature definitions. A new class can be created either from scratch or by deriving it from an existing definition, the parent class, basically by extending the properties of this class. Once the information for a definition has been completed, the resulting class is called a generic specific feature class definition. Such a class can be instantiated when all variables have been specified through parameter values or derived from the feature model. In order to realise such abstractions, a meaningful taxonomy of various types of freeform surface features is stored in a library. The taxonomy can be extended and customised to the user’s own needs.

Fig. 1. The system framework.

3.1.3. Management of freeform surface feature definitions Considering the diversity of the shapes required in freeform feature modelling, it is important to efficiently manage the feature definitions. A freeform feature library management system (FFLMS) has therefore been developed for this purpose. The FFLMS enables a user to (i) define new freeform surface feature classes, (ii) store new feature class definitions, (iii) access previously stored feature class definitions, (iv) modify existing definitions, and (iv) delete existing definitions. It provides an informative interface between the user and the library of freeform surface feature definitions.

used in editing the feature. Furthermore, shape constraints may also be added to control, say, the local shape of the feature or model. Additional parameters and constraints, not intrinsic to a particular feature, may be introduced to the model to enable shape variation that would not be achievable with the parameters and constraints in the features alone. An example of this is the intersection curve between two features. The functionality described in this subsection has been implemented in our framework, for which the system architecture is described in the next subsection.

3.1.4. Facilities for creating freeform surface feature models Evidently, design of features is one thing, design by features is another. Design by features involves creating and editing freeform surface feature models. An advanced feature model should integrate several features (standard, non-standard, or userdefined), explicitly capture feature interactions, and efficiently maintain the imprints of the features on its boundary. We define model creation as the process of inserting features into the model and removing features from the model. The insertion process involves instantiating a feature, positioning and orienting it, and attaching it to other features in the feature model. Unlike traditional feature models, which are only representations of the constituent feature instances, our advanced freeform surface feature model has a generic definition. This definition has a generic shape to which feature, parameter, constraint and relationship definitions are mapped. The generic shape description allows formal parameterisation of the feature model. This, in turn, allows the user to, for example, add new numeric and curve parameters to an already defined feature model, thereby enabling advanced model variation.

3.2. System architecture

3.1.5. Facilities for advanced freeform surface feature model variation Model variation is the process of changing the model’s properties, e.g. parameter values. Essentially, when one considers model variation, a feature model represents a class of objects characterised by a set of parameters and constraints, and not necessarily a representation of a single object. Such a class can be instantiated with parameter values in a way similar to single feature instantiation [4]. In our approach, attaching new parameters to the model also belongs to model variation. For example, a curve on a feature imprint can be formalised as a curve parameter and actually be

The new system architecture, depicted in Fig. 1, consists of five key components: (i) the user and graphical interfaces, (ii) the applications interface, (iii) the FFLMS, (iv) the feature model class, and (v) the databases. 3.2.1. The user and graphical interfaces The user interfaces are the top-level interfaces by which the framework presents itself to the user. Two user interfaces are provided: one for design of features (see Fig. 2), and the other for design by features (see Fig. 3). They provide a consistent look and feel for the user through menus, lists of selectable items, data input interfaces and dialogs, and feedback windows.

Fig. 2. The FFLMS taxonomy browser interface.

P.J. Nyirenda, W.F. Bronsvoort / Computers in Industry 60 (2009) 35–47

39

the BRep. This is essential to consistently map the feature shapes in the unevaluated model to their corresponding imprints in the evaluated model. The partially evaluated model defines a high-level link between the unevaluated and evaluated levels, while maintaining a clear distinction between the shape of each feature and that of the whole model. This is pivotal to the functionality of feature models, because the user interacts with geometry in the graphical interface, even though the shape constructs are features. Design by features is supported through the user interface shown in Fig. 3. The model of a table stand shown in this figure, will serve as a running example to demonstrate the new design facilities in the rest of the paper.

Fig. 3. The design-by-features interface.

Each user interface is supported by a graphical interface, which is exposed in the model display window and is based on HOOPS1, a 3D graphics toolkit [12], which offers various interaction facilities, including selection of geometric elements on the BRep. 3.2.2. The applications interface The applications interface links the feature modeller to the graphical interface. It also provides a link to external applications, e.g. NX, Pro/Engineer or SolidWorks. Currently, this interface defines an Extended Application Programming Interface (EAPI) abstracting the APIs provided by the ACIS1 [13], a 3D geometric modeller kernel. 3.2.3. The freeform feature library management system The FFLMS is responsible for the design of features functionality. It enables the user to create, add, modify and delete feature definitions in the feature library. New feature definitions can be created and added to the library through the class definition interface. Completed definitions can be instantiated once parameter values have been specified through a prototype instantiation interface. Once a basic taxonomy has been created, it can be stored in the database for freeform surface feature definitions. The FFLMS has a taxonomy browser (see Fig. 2), supported by the database browser interface, by which the user can explore the taxonomy of the features already in the library. When a feature type is selected in the taxonomy browser, either (i) a preview of the feature is given (only for generic specific definitions; see Section 3.1), or (ii) the user is allowed to create a new feature class definition. 3.2.4. The feature model class This component, responsible for design by features, comprises the unevaluated model, the partially evaluated model, and the partially evaluated model [4]. The freeform surface feature model class is defined in a manner similar to the feature class definitions by Nyirenda et al. [1], but stores, in addition, explicit references to the feature instances and a generic mapping to the geometric model (BRep), and allows additional model parameters, constraints and other shape definition entities, e.g. points and curves. As mentioned earlier, current commercial feature modelling systems only separately maintain unevaluated and evaluated models. A well-known difficulty with this approach is that feature interactions are only implicitly implemented at geometry level, in the geometric boundary evaluator, i.e. in the BRep [14]. The partially evaluated model enables the feature model to explicitly capture and store feature interactions at a level that is higher than

3.2.5. The databases Two libraries are maintained: one for storing freeform surface feature definitions; another for storing freeform surface feature model definitions (see Fig. 1). Feature definitions are organised in ‘bodies’ reflecting the structure of a feature class comprising (i) class name, (ii) superclass name, (iii) constructors, (iv) parameters, (v) constraints, (vi) methods, and (vii) shape definition entities (see Section 4). This information is represented in entity-relation structures. A stored feature model includes references to parametric information that includes (i) explicit links to specific parametric feature definitions, (ii) model parameters, (iii) model constraints, (iv) additional model shape entities, all stored in unevaluated form; values are stored separately (see Section 5). The storage of generic entities guarantees precision and avoids the explosion of data, often encountered when evaluated geometry (say, a BRep) is stored instead. In our approach, geometry is generated from the parametric definitions after instantiation. This makes our database very easy to manage. 4. Feature class definition This section discusses, in detail, freeform surface feature class definition. 4.1. The class structure The structure of a feature class includes one or more constructors, a shape description, parameters and constraints as depicted in Fig. 4. 4.1.1. Constructors A constructor is a special method responsible for allocating the memory necessary to create a feature class instance. It has a signature in which the arguments are the parameters needed to instantiate the class definition. 4.1.2. Shape A generic freeform surface feature shape definition encapsulates two shape descriptions: basic shape and fine shape. The former represents the global shape of the feature, whereas the latter refers to the local shape within the basic shape. For example, the character lines on the model in Fig. 3 constitute the fine shape on the basic shape (the table foot). Shape is described using feature definition entities of three basic types: FFDPoint, FFDCurve and FFDSurface; see Fig. 2. An FFDPoint is a generic 3D point defined by an origin and a position vector in Euclidean space (E3). It can also be specified by a distance from the origin and an angle to a reference line in a plane, as in [15]. An FFDCurve is an ordered set of FFDPoints; an FFDSurface is an ordered set of FFDCurves and/or FFDPoints.

40

P.J. Nyirenda, W.F. Bronsvoort / Computers in Industry 60 (2009) 35–47

Besides, each feature shape has a special FFDPoint, called the key reference point, used to define a reference for the feature in the model. The feature shape is defined by one or more methods (see Fig. 4). These are used for creating geometry and establishing links with other features, e.g. when the feature is attached to the model. One method describes how the specified parameters and constraints relate to the shape definition entities within the feature, and other methods may take into account references to external model entities. The latter is one of the reasons for storing relation information, which a feature may have, in the feature class definition. 4.1.3. Parameters Parameters can be numeric or curve-based. The former are modified by value, e.g. changing a dimension of a feature in a model, whereas the latter are modified by reference, e.g. by selecting and dragging an FFDCuve in the model. Interested readers may consult Nyirenda and Bronsvoort [4] for details. Fig. 4. Generic class structure.

FFDCurves and FFDSurfaces define a geometry representation in NURBS curves, respectively, surfaces. The NURBS curves interpolate FFDPoint positions (see again Fig. 2). An FFDSurface defines one or more NURBS surfaces, which interpolate FFDCurves and/or FFDPoints in the shape definition. The ACIS1 geometric modeller kernel [13] is used to provide the geometry representation level functionality. The feature definition entities have been introduced to associate high-level information with the geometric points, curves and surfaces, and to ease the creation of feature geometry. For instance, an FFDPoint may encapsulate constraints on distances and angles. An FFDCurve includes properties indicating whether the resulting NURBS curve should be open/closed, periodic/non-periodic. FFDSurfaces include information about specific interpolation algorithms, such as point fitting, skinning, sweeping or lofting [10], to be used for generating the shape. For example, the basic shape of the feature shape in Fig. 2 could be created by skinning the FFDCurves in the FFDSurface. Its fine shape can be created by modifying the FFDCurves and/or any combination of FFDPoints in the basic shape definition.

4.1.4. Constraints A feature class can also have parameter constraints and/or shape constraints. Parameter constraints affect parameter values, whereas a shape constraint restrains the shape. Constraints are defined by target entities and associated conditions. In a parameter constraint, the target entity is a parameter, whereas a shape constraint refers to a feature entity. The condition represents the properties to be maintained by the target entity in the lifetime of the feature. Example parameter constraints are value and flexure constraints [4]. A value constraint limits the allowable parameter value’s range; a flexure constraint, say on an FFDCurve, declares whether, when an FFDPoint in the curve is displaced, the curve should deform globally (condition: rigid) or locally (condition: flexible). An example of a shape constraint is a curvature constraint, which declares, for instance, the maximum allowable curvature in the feature shape. 4.2. The taxonomy A taxonomy is a classification of features into subgroups based on their properties. This enables the storage and management of freeform surface features in a library of feature definitions. To the best of our knowledge, no commercial system offers design with an

Fig. 5. Part of taxonomy.

P.J. Nyirenda, W.F. Bronsvoort / Computers in Industry 60 (2009) 35–47

expressive taxonomy for freeform surface features. Probably, the main reason for this is the diversity in their properties and the complexity of their shapes. Research on freeform feature taxonomies, in an effort to cover a wide scope of freeform features, dates back to 1990s. Fontana et al. [16] categorise features, for aesthetic design, based on deformation and elimination operations. Pernot et al. [17] present a taxonomy based on surface deformation techniques, also for aesthetic design, but less formal compared to the former. Nyirenda et al. [18] present a generic taxonomy independent of application domain, which classifies freeform features based on shape characteristics, and refers to the nature of the feature, and to its relative topology (internal, border, channel, or isolated) in the feature model; see Fig. 5. Nature indicates whether the imprint of the feature shape in the feature model is material displacement, removal or addition. Relative topology defines the feature imprint’s position relative to other feature imprints on the feature model boundary [1]. For example, the trough feature in Fig. 3 is internal relative to the table foot, and isolated relative to the pocket feature. This taxonomy is not based on (geometric) construction method, to enable to always use the most appropriate method to create the feature. In this taxonomy, freeform features are categorised into deform, cut, transition and compound. Deform features are protrusions representing material displacement in the model, i.e. they have a substitutive nature. In this paper, the taxonomy has been extended to classify features into families by their basic shape parameters for expressiveness. To this end, shape characteristics, e.g. basic shape parameters height and width, can be used to identify the feature type, e.g. Deform-HW in Fig. 5. This is expressive because users often perceive shape in terms of dimensions, e.g. H(eight) and W(idth). For instance, the ridge feature in Fig. 6(a) is characterised by several heights, widths and lengths—it belongs to Deform-HWL; the tube feature in Fig. 6(b) is defined by several lengths and radii (is Deform-LR), and so on. A cut feature represents material removed from the model (subtractive nature), e.g. a hole feature. Transition features represent connecting features and may have an additive or a subtractive nature, e.g. a blend feature can be additive or subtractive. A compound feature is a combination of any of the basic features (i.e. deform, cut or transition). The FFLMS is based on this extended taxonomy, which defines the organisation of the feature definitions in the feature definition library database. When the user selects a feature type in the taxonomy browser, its class’ representation (see Fig. 4) is presented. This representation is generated from the corresponding class in the database. Only information pertinent to the feature type at hand is presented, i.e. only the parameters, constraints and methods that are either new or overridden in the super-classes are included in this class representation.

41

4.3. Design of features A new feature class can be created using either language-based feature definition (LBFD) or interactive feature definition (IFD) techniques. In LBFD, new feature types are defined through textual interfaces using either feature classes [1,6], feature class frames [19], or variants. In IFD, feature types are created by specifying a set of entities in the graphical interface and attaching parameters and, possibly constraints, to the entities. LBFD is less prevalent in commercial systems compared to IFD. In IFD, sketches are used to create geometric elements to be used to instantiate feature definitions. Still, the main limitation is that these systems basically use these sketches as front-end inputs to instantiate (pre-defined) features: translational sweeps (or protrusions), rotational sweeps and skinning. Stated differently, they do not support creating completely new parametric feature definitions. 4.3.1. Language-based feature definition An LBFD method for freeform surface features was presented by Nyirenda et al. [1]; it is summarised in Fig. 7. Basically, a super-user (responsible for creating new feature class definitions) selects a super-class (parent class) from which to derive the new class definition, and supplies the name for the new feature. If the new class is derived from a generic abstract class, more than one constructor will normally be offered. Only one constructor may be selected for the new class. The constructor may be extended with additional input parameters and, possibly, constraints, which should be specified at class instantiation. Shape definition entities may then be declared, and parameters and constraints can be defined on these entities as needed. New methods can be defined through either overriding some of the methods in the super-class or by adding methods to the new class. As an example, consider the table foot feature in the model of the table stand introduced earlier in Fig. 3. Its basic shape parameters are depicted in Fig. 8, and the corresponding class definition shown in Fig. 9. It is derived from the Deform-HRDome class level to create a completely new type of feature characterised by a height (H), a width (W), a length (L), four radii (R) and domeness (Dom) as parameters. The domeness parameter specifies the roundness on the closed end of the feature (see Fig. 8(c)). The LBFD will not be discussed further in this paper. 4.3.2. Interactive feature definition In current approaches to IFD, one starts to work with partial definitions, using sketching facilities, of a product. At this stage, not all parameters are available to complete the definition of the intended feature. The construct evolves progressively as the sketch is being detailed. The geometric points and curves in the sketch are

Fig. 6. Feature characteristics: (a) ridge feature: Deform-HWL type; (b) tube feature: Deform-LR type.

42

P.J. Nyirenda, W.F. Bronsvoort / Computers in Industry 60 (2009) 35–47

Fig. 9. Class definition for table foot.

Fig. 7. Feature class definition scheme.

used to instantiate features, e.g. extrusions, pre-defined in the system. Sketches are often created on planes, but some systems allow sketches on model boundary with restrictions, e.g. that a sketch may not span more than one face on the model boundary. In this paper, a sketch is used to specify generic geometry for the intended feature class.

Fig. 8. Table foot feature (a) new feature DeformHWLRDome type is selected, (b), (c) parameter definitions.

First, the user is prompted to select a feature type in the taxonomy browser. In our examples, DeformHRDome is selected (see Fig. 8(a)); the system then displays a preview for the feature type. Here, the user wants to derive a new feature class definition from the currently selected one. It will have a different number and different types of parameters, and a different number of FFDCurves from the prototype in the preview. Second, the user is prompted for input geometry entities for the intended feature. Sketching facilities are used to accomplish this task. The sketch will define the number and types of the feature definition entities to be used in specifying the feature shape description. Again, notice that sketching is used to create the generic FFDPoints and FFDCurves. In fact, sketch points and curves become geometry representations for the FFDPoints and FFDCurves, respectively, and can later be manipulated by their generic counterparts. One FFDCurve may encapsulate several geometric curves, thereby allowing sketches to span several faces on the model boundary. Sketch geometry is not stored in the class definition; only the FFDPoints and FFDCurves. This allows us to later manipulate FFDPoints and FFDCurves in the feature definition, independent of the sketch geometry. This is different from the current approaches where only sketches may be used to edit the generated feature, which forces a roll back in the model history first, just to edit the sketch prior to regenerating the updated shape. Two methods can be used: (i) sketch entities on reference planes, and (ii) sketch entities on the boundary of an existing model. In the following two examples, we use the first method to create the table foot class definition, and the second to create the trough feature class definition. 4.3.3. Example 1: sketching on reference planes Since the currently selected parent class is DeformHRDome, some of the properties, e.g. height, radius and dome parameter definitions and methods will be available. However, we intend to derive a new DeformHWLRDome class. The system uses point and curve elements from a sketch to create FFDPoints and FFDCurves, respectively, in the new feature class definition. In this example, two curves are created on two parallel planes offset from each other by distance H. The two curves are captured using two FFDCurves {c1, c2}, respectively, as shown in Fig. 10. The user then selects the side of the domeness; here the +Z-direction was selected. The FFDCurve in the direction opposite the +Z-direction (the Z-direction) is the first FFDCurve in the new feature class definition. Next, each of the basic parameters, i.e. H, R and Dome, are prompted by the system. There is one H, four Rs (for each corner, e.g. R1, R2 in Fig. 8(b)) and Dom.

P.J. Nyirenda, W.F. Bronsvoort / Computers in Industry 60 (2009) 35–47

43

constraints or even parameters, points and curves, as needed. Thus, the user can see the effect of additional properties in the prototype feature, while the system automatically updates the class definition in the background for the user. In this way, endusers are also able to interactively extend existing feature definitions; another contribution of this paper. 4.4. Prototype instantiation

Fig. 10. Sketch definition.

Furthermore, other parameters than H, R and Dome types in the selected parent class are prompted. Our new class requires width (W) and length (L) parameters as additional parameters for the table foot. Since our framework offers a set of ready to use generic parameter definitions for height, length, width, radius, domeness, and so on, the user can simply select them from a menu in the user interface. Other user-defined parameter types (see [4]) are also supported. Next, the user is prompted for the entities that the parameters should be associated with, e.g. the length L is specified between FFDPoints {p2, p7} in Fig. 10. Finally, constraints are requested. There is only one constraint here defined in the sketch, i.e. that the two FFDCurves {c1, c2} should be parallel. At this point, the information about the feature is complete; its representation is shown in Fig. 9. Actually, the system internally guides the user through the steps formalised in Fig. 7, here too, to create a new class definition.

Completed class definitions can be instantiated. From the user viewpoint, it is useful to have a visual impression of the feature shape, whereas from the FFLMS perspective, it is important to store a valid class definition. The prototype instantiation interface of the FFLMS converts the information of the selected class from the database to a C++ template for the purpose of preview. A temporary executable source file is created for instantiation using a C++ interpreter. Valid feature definitions can be permanently stored as predefined classes in the feature definition library. This approach significantly reduces the amount of information that needs to be stored per feature class definition, because the entity-relation structures in the database avoid replicating class information. 5. Freeform surface feature model specification This section details the specification of a freeform surface feature model. First, model definition is summarised, followed by model representation. Finally, model creation is explained. 5.1. Model definition

4.3.4. Example 2: sketching on model boundary This approach is best suited to creating new feature class definitions with the help of a feature model. It will be illustrated by creating the trough feature class definition, again by deriving the new class from DeformHRDome. A sketch created on the model boundary is used to define the FFDCurve c1, shown in Fig. 11(a). Next, the user creates the free 3D curve, and uses sketching facilities to snap the new curve, c2, to c1 (see Fig. 11(b)). Different camera positions on the current situation are used in Fig. 11(c) and (d). As in the previous example, the user is prompted for parameters for the new class definition. With the information completed, a prototype of the feature, see Fig. 11(e), is displayed. The user may edit the prototype, e.g. by adding

A feature model is defined using a feature model class that comprises an unevaluated, a partially evaluated and an evaluated model representation [4]. Like a feature class definition, this definition constitutes parameters (referred to as model parameters), constraints (referred to as model constraints), and a generic shape, called feature model shape, characterised by shape definition entities (e.g. FFDPoints and FFDCurves). Unlike a feature class definition, a feature model class definition can be extended after instantiation, e.g. by adding new features or other new entities, e.g. parameters. It also facilitates capturing intersection entities, e.g. intersection curves, in the partially evaluated model. In addition, reference geometry such as planes and axes can also be added. A feature model class instance is created once at least one feature instance has been assigned to its definition. The feature model shape definition evaluates to a concrete shape as an aggregate of all the constituent feature shapes and model entities. Each time the model is edited, its model shape is re-evaluated to generate the updated geometry. 5.2. Model representation

Fig. 11. Creating the trough feature class, (a) curve, c1, sketched on model boundary; (b) new curve, c2, created and constrained to the previous curve c1; (c), (d) different camera positions of (b); (e) prototype of the new feature instantiated.

The freeform surface feature model defines three levels for its representations: unevaluated, partially evaluated and evaluated models. The unevaluated model is the highest level of abstraction, constituting a structured set of individual freeform surface features, each with its own canonical feature shape. The key element is the FDG, which keeps track of the structure of the feature model in terms of relations among the features and other model entities. The FDG contains references to all feature instances. Each feature has its own set of entities (see Section 4). The FDG may also include model parameters, model constraints, and additional shape definition entities. Basically, an FDG is a directed acyclic graph constituting all model entities

44

P.J. Nyirenda, W.F. Bronsvoort / Computers in Industry 60 (2009) 35–47

Fig. 12. Inserting feature instances: (a) feature shapes in freeform surface feature model; (b) the FDG.

and dependency relations among them. This representation eliminates the need for history-dependent model evaluation, which has several advantages; see [5]. The partially evaluated model explicitly defines a bidirectional link between the unevaluated and evaluated models, while maintaining a clear distinction between the shape of each feature and the shape of the whole model. This extension to the current dual-representation structures is motivated by the need to consistently map individual feature shapes in the unevaluated model to their representations in the evaluated model (i.e. feature shape imprints on the model boundary). As an intermediate, relational interface, the partially evaluated model enables dynamic extension of the feature model and maintenance of associations between its entities. This is possible through an interaction data structure defined to capture the BRep elements created by feature interactions, e.g. intersection edges and subset faces, in generic entities, e.g. FFDCurves and FFDSurfaces [4]. Importantly, this data structure can be used to effectively vary the feature model shape, as illustrated in Section 6. The evaluated model is the lowest level of abstraction; a BRep of the feature model shape. It is derived from the partially evaluated model, and constitutes only those entities on the model boundary. 5.3. Model creation Model creation involves (i) inserting feature instances (ii) attaching the instances to the feature model, and (iii) evaluating the overall shape of the model. 5.3.1. Inserting feature instances Feature insertion encompasses (i) instantiating freeform surface feature classes, and (ii) positioning and orienting the feature shapes. Feature definitions are retrieved from the library, and instantiated in the model when all parameters have been specified or derived from the model. The system then displays the prototype feature. Fig. 12(a), our example feature model, currently contains three feature shapes. Before model evaluation, the table foot’s feature shape contains a single feature face. The hole feature shape is at the base of the pocket feature—not visible in Fig. 12(a), but in Fig. 13(c). The table foot feature was inserted first, and then the pocket feature relative to the table foot feature shape. Finally, the hole feature was specified relative to the pocket. All feature positions and orientations are captured by model parameters. 5.3.2. Attaching features A feature attachment encompasses two phases (i) attachment definition, and (ii) attachment evaluation. In attachment definition, the user specifies attach faces by selecting faces, on the features, to couple, e.g. on the table foot and pocket features. An attachment definition specifies: dependency and attach relations. First, a dependency relation defines a parent/ child relationship between the features being attached. In this case, the table foot is the parent and the pocket is the child. These relations are recorded in the FDG, as annotated in Fig. 12(b).

Second, an attach relation couples the selected feature faces—the parent feature provides the support face. If necessary, relative topology could be used to add a position constraint on the attached features. For instance, the pocket feature face is internal to the table foot’s feature face. Once attachment definition is completed, attachment evaluation follows automatically. In this phase, the partially evaluated model performs a pair-wise imprint operation between the features with dependency relations. At the BRep level, this process creates new intersection vertices and edges, and splits edges and faces. The subset faces so created are shown in Fig. 13; the table foot feature face now refers to two subset faces {f1, f2} and the pocket feature face to {f3, f4}. All this information is captured by entities in the partially evaluated model. The objective is to represent feature interactions at a level that is higher than the BRep. Basically, the interaction data structure defines a robust mapping between the feature shapes, in the unevaluated model, and the corresponding imprints in the evaluated model, and associations between the imprints of different features. 5.3.3. Model shape evaluation The feature model shape is evaluated to create a BRep. The BRep is used to represent and visualise the entities in the model’s shape. A selection mechanism is provided to enable picking parametric entities in the graphical interface and to change their values. The feature model class has several methods to evaluate its shape from several features. The FDG supplies the information needed for the evaluation. The order of feature evaluation respects the precedence ordering of the FDG, and not the model history. The nature of each feature is mapped to particular Boolean operation in the underlying geometry kernel, e.g. subtractive nature to Boolean difference. In solid models, it is easy to identify

Fig. 13. Attachment evaluation, (a) imprint performed on the interacting features, (b, c) subset faces {f1, f2, f3, f4}, and intersection curve (ic) have been created.

P.J. Nyirenda, W.F. Bronsvoort / Computers in Industry 60 (2009) 35–47

on-boundary faces, but this is not always the case in surface models. For instance, from the faces {f1, f2, f3, f4} in Fig. 13, automatic boundary evaluation might retain unwanted faces, because the in/out classification is ambiguous for surface models. In order to avoid such ambiguities, we allow the user to select which of the faces to retain in the final model boundary. However, faces of negative features are always removed from the model boundary. In order to create the model introduced earlier in Fig. 3, the faces we have to retain in Fig. 13 are {f1, f3}. Note that the partially evaluated model retains all the interaction entities, including those removed from the model boundary. The intention is to maintain the functional relationships between the features and their imprints in such a way as to facilitate certain interrogations on the model, e.g. parent/child relations among split topologies. The interaction data structure is further exploited in the next section.

45

An intersection curve parameter captures the intersection curve between two feature shapes, e.g. ic in Fig. 13, with the intention to manipulate the intersecting features. A new definition, called FFDCrossCurve, is provided for this purpose. 6.1.2. Model constraints Two types of model constraints can be identified: parameter and shape constraints. The former apply to model parameters; the latter to the model shape. Unlike feature constraints (in feature definitions), model constraints can be imposed on several features, e.g. an algebraic constraint on two parameters from two features to allow manipulating the two features simultaneously. 6.2. Parameter attachment

Feature and model parameters are used to edit the shape of the model. Constraints can be added to the feature model through the parameters. This is possible because our new framework provides generic definitions for both numeric and curve parameters.

A model parameter should be first attached for it to be used to edit the model. Facilities in the partially evaluated model make advanced parameter attachment possible. Curve parameter attachment involves more steps than needed for numeric parameters. A parameter attachment encompasses attachment definition and evaluation. In parameter attachment definition, the parameter’s attributes should be specified, namely: (i) reference entity, (ii) direction of evaluation (iii) manipulation entity, and (iv) influence entity. A reference entity, the entity against which the parameter is evaluated, can be a reference plane, an FFDPoint or a vertex in the model. The direction of evaluation is the direction in which the parameter is evaluated; it can be linear (vector) or curvilinear (arbitrary curve). For instance, a numeric parameter value can be evaluated along a vector or an FFDCurve. A manipulation entity is an entity through which the influence of the parameter is propagated to the model (for numeric parameters), or an entity through which the designer manipulates the model and to which the value of the parameter is measured in the model from the reference entity (for curve parameters). A manipulation entity can be an FFDPoint or a vertex. Influence entities are entities, owning manipulation entities, by means of which the model shape is influenced. These attributes for curve parameters are depicted in Fig. 14. The arrow is a handle provided to the user to manipulate the model. An on-model curve parameter is defined by creating an FFDCurveOnSurface on the model boundary, as shown in Fig. 14. The user is prompted for the manipulation entities, i.e. the entities that can be used to manipulate the model shape, in the FFDCurveOnSurface. One or more FFDPoints in this FFDCurve can be specified. To define an intersection-curve parameter, the user specifies the two intersecting features. For instance, the intersection edge (ic) in Fig. 13 would be captured by the FFDCrossCurve when the table foot and pocket are specified.

6.1.1. Model parameters Model parameters have corresponding class definitions, which encapsulate several properties, e.g. to allow constraint specification, and methods describing the way their instances will be manipulated. Two types of model parameters are distinguished: numeric and curve parameters. The former are manipulated by value, whereas the latter are manipulated by reference. A model curve parameter can be: (i) an on-model curve parameter, or (ii) an intersection curve parameter. An on-model curve parameter is specified on the model boundary and can span several features. The framework provides a new type, called FFDCurveOnSurface to define on-model curve parameters. It encapsulates one or more curves on surfaces, created either by sketching or by projecting curves onto the model boundary.

Fig. 14. Attaching on-model curve parameters.

6. Feature model variation Freeform surface feature model variation will be presented in this section. Model variation is the process of changing properties of the feature model, such as through editing values of numeric parameters or positions of curve parameters. As stated earlier, in our approach, model variation also includes the attachment of new parameters to the feature model. Although curves have been used to manipulate surfaces, notably in Fontana et al. [16] and Pernot et al. [17], this has been mainly been done in the context of aesthetic design. However, curve parameters are also needed in engineering design, and this is made feasible in this paper. In Pernot et al. [17] curves are modelled as ‘features’, not as parameters. This conception differs from the definition of a feature given by Shah and Ma¨ntyla¨ [6] – see Section 2 – which forms the basis for our definition of freeform surface features. Basically, we consider such curves to be parameters. Because of this, we have been able to develop a generic parameter definition from which both numeric and curve parameters are derived. Each parameter can encapsulate high-level properties needed for intuitive freeform surface shape specification. In this section, first, model parameters and constraints are summarised, and then parameter attachment is explained. Finally, model variation is presented. 6.1. Model parameters and constraints

46

P.J. Nyirenda, W.F. Bronsvoort / Computers in Industry 60 (2009) 35–47

Fig. 15. Target shape created by on-model curve parameters, (a) target curves, c1 and c2 inserted in the model relative to the reference plane; (b) c1 and c2 mirrored to make four target curves - display in a different camera position; (c) numeric parameters constrain the position of the pocket feature shape.

6.3. Model variation

Fig. 16. The model shape boundary, (a) the table foot deforms in a constrained manner to take a shape defined in Fig. 15; (b) the trough feature is determined using c1 and c2; (c) shaded camera view of Fig. 16 (c).

Once parameter definition is complete, parameter attachment evaluation proceeds automatically. For example, a handle is displayed on each parameter manipulation entity (see Fig. 14). This means the parameter is ready to be used. It is important to notice here that parameters are attached to FFDPoints and FFDCurves, instead of BRep elements. The use of unevaluated entities guarantees reliable parameter specification. It also offers additional entities for parameter attachment. For example, in a BRep, only at the end of a curve a vertex occurs, whereas an FFDCurve has several FFDPoints.

Only feature parameters or attached model parameters may be used to edit the model shape. In order to create the model introduced in Fig. 3, the FFDCurveOnSurface parameters in Fig. 14 and the FFDCrossCurve (from ic in Fig. 13) are edited. It can be observed that the shape of the table stand, in Fig. 3, has a recess at the bottom as annotated in Fig. 16(a). In order to obtain this recess, the end FFDPoint p11 must remain fixed and p12 must move (in Fig. 14), when the curve parameters {c1, c2} are translated upward. The user drags the handle in Fig. 14 to translate c1 to a new position—shown in Fig. 15(a). Since there are two curve pairs mirroring each other (see Fig. 15(b)), an algebraic constraint is specified to couple the parameter pairs. In this way, only one of the curves in each pair can be manipulated. The result is shown in Fig. 15(b). Next, two other design modifications need to be made. First, during model creation (in Section 5.3, see Fig. 12), the position of the pocket feature was captured by the model. Since this position is critical to the design of the table stand, the user adds a parameter h1; see Fig. 15(c), on which a value constraint is then declared. Second, the user might want to make changes that would make the table foot distort the shape of the pocket. The objective is to prevent such a distortion. Using the new facilities, an FFDCrossCurve (ic) parameter is defined on the intersection between the pocket and table foot, as shown in Fig. 15(c). A flexure constraint is then declared on this parameter, as rigid, in order to preserve the shape of the pocket feature. By sliding the rigid curve along the face of the pocket feature shape (shown in Fig. 12) the table foot feature shape is deformed without modifying the pocket feature shape. Finally, the trough feature is inserted; the resulting model is shown in Fig. 16(b) and (c). The model can be seen from a different position in Fig. 17(a). The trough feature is edited by changing the (numeric) feature parameters {h1, w1}. The modified model is shown in Fig. 17(b).

Fig. 17. Feature model variation using numeric parameters, (a) the complete, evaluated, model with the trough feature; (b) the local trough feature w1 and w2 are edited – other parameters are held fixed.

P.J. Nyirenda, W.F. Bronsvoort / Computers in Industry 60 (2009) 35–47

7. Conclusions This paper has demonstrated new surface feature modelling facilities. These include several techniques for creation of userdefined freeform surface features, model specification and model variation. User-defined features can be created using language-based techniques as well as interactive techniques. In language-based techniques, a textual interface is used to create new feature class definitions. In the interactive technique, sketching facilities are used to create generic entities. With the possibility to create prototype feature instances of the class definitions, the definitions can be visually checked by the user before saving them to the library of freeform surface feature definitions. The creation of feature class definitions is supported by the FFLMS, which is responsible for managing the freeform surface features. The taxonomy, which is its main component, classifies freeform surface features according to their properties, e.g. parameters. This makes definition of new features simpler and more consistent. The entity-relation structures in which feature definitions are structured in the library database make retrieval very efficient, and the library size significantly smaller compared to storing BRep data, as most current systems do. The new freeform surface feature model includes the partially evaluated model, which, for example, explicitly captures feature interactions. This allows the model definition to be extended with new parameter definitions. Constraints can also be declared on the parameters, e.g. a flexure constraint to specify whether a curve parameter should change globally or locally. The various types of parameters introduced by the framework can be used to effectively vary the feature model within constraints dictated by functional requirements. Finally, the example model presented in this paper, and several other models, turned out to be much easier to create using our techniques than with standard modelling techniques, using a popular, commercially available CAD system. We therefore believe the facilities offered by our framework can be very useful. References [1] P.J. Nyirenda, M. Mulbagal, W.F. Bronsvoort, Definition of freeform surface feature classes, Computer-Aided Design and Applications 3 (5) (2006) 665–674. [2] J.P. Pernot, B. Falcidieno, F. Giannini, J.C. Le´on, Incorporating free-form features in aesthetic and engineering product design: state-of-the-art report, Computers in Industry 59 (6) (2008) 626–637. [3] V. Shapiro, D.L. Vossler, What is a parametric family of solids? in: C.M. Hoffmann, J.R. Rossignac (Eds.), Proceedings of the Third ACM/IEEE Symposium on Solid Modeling and Applications, Salt Lake City, USA, May 17–19, ACM Press, New York, 1995, pp. 43–54. [4] P.J. Nyirenda, W.F. Bronsvoort, Numeric and curve parameters for freeform surface feature models, Computer-Aided Design 40 (8) (2008) 839–851. [5] R. Bidarra, W.F. Bronsvoort, Semantic feature modelling, Computer-Aided Design 32 (3) (2000) 201–225. [6] J.J. Shah, M. Ma¨ntyla¨, Parametric and Feature-based CAD/CAM—Concepts, Techniques and Applications, John Wiley & Sons, New York, 1995.

47

[7] W.F. Bronsvoort, R. Bidarra, P.J. Nyirenda, Developments in feature modelling, Computer-Aided Design and Applications 3 (5) (2006) 655–664. [8] C.M. Hoffmann, R. Joan-Arinyo, Parametric modeling, in: G. Farin, J. Hoschek, M.S. Kim (Eds.), Handbook of CAGD, Elsevier, 2002, pp. 519–541. [9] R. Bidarra, J. Madeira, W.J. Neels, W.F. Bronsvoort, Efficiency of boundary evaluation for a cellular model, Computer-Aided Design 37 (12) (2005) 1266–1284. [10] L.A. Piegl, W. Tiller, The NURBS Book, 2nd ed., Springer, Berlin, 1997. [11] A. Bernard, The feature approach for the integrated design and machining of forming dies, Robotics and Computer-Integrated Manufacturing 10 (1/2) (1993) 71–76. [12] TechSoft3D, HOOPS documentation, 2007, http://developer.hoops3d.com/documentation/Version16. [13] Spatial, ACIS R18 online documentation, 2008, www.spatial.com. [14] G.A. Crocker, W.F. Reinke, An editable non-manifold boundary representation, IEEE Computer Graphics & Applications 11 (2) (1991) 39–51. [15] E. van den Berg, H.A. van der Meiden, W.F. Bronsvoort, Specification of freeform features, in: G. Elber, V. Shapiro (Eds.), Proceedings of the Eighth ACM Symposium on Solid Modeling and Applications, Seattle, USA, June 16–20, ACM Press, New York, 2003, pp. 56–64. [16] M. Fontana, F. Giannini, M. Meirana, A freeform feature taxonomy, in: P. Brunet, R. Scopigno (Eds.), Proceedings of Eurographics, Computer Graphics Forum, 18 (3) (1999) 107–118. [17] J.P. Pernot, S. Gillet, J.C. Le´on, B. Falcidieno, F. Giannini, Shape tuning in fully freeform deformation features, Journal of Computing and Information Science in Engineering 5 (2) (2005) 95–103. [18] P.J. Nyirenda, W.F. Bronsvoort, T.R. Langerak, Y. Song, J.S.M. Vergeest, A generic taxonomy for defining freeform feature classes, Computer-Aided Design and Applications 2 (1–4) (2005) 497–506. [19] T. Laako, M. Ma¨ntyla¨, A feature definition language for bridging solids and features, in: J. Rossignac, J. Turner, G. Allen (Eds.), Proceedings of Second Symposium on Solid Modeling and Applications, Montreal, Canada, May 19–21, ACM Press, New York, 1993, pp. 333–341.

Paulos J. Nyirenda is currently a consultant in the Fluid Structural Dynamics Department (Oil and Gas) at TNO in Delft, The Netherlands, since March 2008. He received his master’s degree in mechanical engineering from the University of Zambia in 2000. He obtained his PhD from Eindhoven University of Technology in mechanical engineering in 2004. Since then, until March 2008, he worked as post-doctorate in computer science at Delft University of Technology in the Computer Graphics and CAD/CAM Group, at the Faculty of Electrical Engineering, Mathematics and Computer Science. His primary interests are geometric modelling, including freeform feature modelling, software (application) design, architecting and scientific software development. Other interests include design, design analysis (CFD, FEA), and manufacturing, e.g. in turbomachinery.

Willem F. Bronsvoort is associate professor CAD/CAM at the Faculty of Electrical Engineering, Mathematics and Computer Science of Delft University of Technology, The Netherlands. He received his MSc degree in computer science from the University of Groningen in 1978, and his PhD degree from Delft University of Technology in 1990. His main research area is feature modeling, in particular semantic feature modeling, multiple-view feature modeling, freeform feature modeling, and mesh generation from feature models. He has published numerous papers in international journals, books and conference proceedings, is on the editorial board of several journals, and has served as co-chair and member of many program committees of conferences.