Defeaturing
The ACIS Defeaturing Component supplies functionality that recognizes and/or removes "features" from an ACIS model. Operating in default mode, the interface function api_find_and_remove_features recognizes sets of faces on the model whose geometry are consistent with standard feature shapes and removes them. Through the use of an options object, parameters that control whether a particular shape is recognized as a feature (such as the maximum diameter of holes) can be modified from their defaults. In addition, by using an options object, you can stop the process after feature recognition (and before feature removal), examine the features that were found, and/or specify features that should not be removed before proceeding to feature removal. This supports a typical workflow that you may want to expose to your end users.
Topics include:
- Interface
- Features
- Limitations
- Workflow
- Default Parameter Settings
- Flowchart for Workflow
- Permitted Operations
- Error Reporting
- Scheme Interface
Interface
The interface to defeaturing contains two signatures of the API function api_find_and_remove_features:
outcome api_find_and_remove_features( BODY* input_body,
defeature_options* dfopts = NULL,
AcisOptions* aopts = NULL );
outcome api_find_and_remove_features( const ENTITY_LIST& input_bodies,
defeature_options* dfopts = NULL,
AcisOptions* aopts = NULL );
Note that the two signatures differ only in taking a single body versus taking a list of bodies. The single body signature serves as a convenience routine; it produces the same results as the "list of bodies" signature called with a single body in the list.
Use the defeature_options object to configure the behavior of the API functions. The defeature_options object fulfills three roles:
- Manages the settings for parameters which control whether a particular shape is recognized as a feature (for example, the maximum diameter of holes), and provides reasonable defaults.
- Controls whether api_find_and_remove_features performs only feature recognition, or feature recognition and removal.
- Provides an interface for managing and viewing the features to be removed; methods to obtain the number of features recognized, and methods to obtain a list of faces corresponding to each feature. In addition, the options object allows you to specify features that are not to be removed by calling the keep_face method on any face in the feature. Finally, the options object allows you to query the number and faces corresponding to features which were marked for removal but not removed (through the failed_feature methods).
In general, the options object manages parameters through get_* and set_* methods. For example, the methods get_hole_max_diameter and set_hole_max_diameter control the hole_max_diameter parameter. Calling a set function without any arguments resets the parameter to its default value. Calling the routine without an options object is equivalent to passing in a default options object.
Features
Supported features include:
- Holes (cylindrical, conical, spherical and toroidal): Holes that are split along or across axis due to interaction with other features are recognized as a single hole only if they are completely overlapping along their axis. Partial overlap holes are not recognized as a single hole feature. Filleted holes are recognized as toroidal holes and not as a hole and a fillet. Partial spherical holes where the angle of wrap is less than 360 are not recognized. If a spherical hole is cut, it is recognized only if the cut is normal to the axis. Partial holes and bosses are not supported.
- Chamfers
- Blends (constant radius and variable radius): Constant radius as well as variable radius blends are supported. Blend chains are recognized as single features.
Limitations
Defeaturing limitations include:
- The bodies passed into the defeaturing API must be manifold.
- Although the defeaturing API recognizes blends whose faces have been split, currently these blends cannot be removed. Refer to the following figure for an example of a blend with a split face.
Figure. Blend with a split face
Workflow
Typical customer workflows using ACIS Defeaturing include:
- Calling the defeaturing API without an options parameter, whereupon the features in the body are recognized and removed as specified by the default parameters.
- Changing the default parameter settings and specifying which features are to be recognized and whether any of those features should not be removed.
The second workflow typcially proceeds as follows:
- Create an options object and call methods to configure it as follows:
- Enable pause_after_recognize; the API stops after the recognition stage has been performed.
- Adjust feature recognition parameters.
- Mark any faces not to be removed by feature recognition by calling the keep_face method.
- Call the defeaturing API. This results in the following state changes:
- Set recognize_done to TRUE. This prepares the options object to be used by the second pass through the defeaturing API.
- The Defeaturing component generates data about the features recognized. Access the data by the get_num_features and get_feature methods of the options object.
- The topology of the bodies being operated upon remain unchanged, because feature removal is disabled.
- The options object moves into a state where changing the feature recognition parameters is not allowed, and results in an error if attempted. This ensures that the recognition and removal phases are called with the same feature recognition parameters in place.
- Use the get_num_features and get_feature methods of the options object to display information to the end user about which features were recognized. You may allow your end user to specify features which should not be removed, and notify the defeaturing package of these features by passing one or more faces in each feature to the keep_face method of the options object.
- Call the defeaturing API a second time with the same options object. This results in the following state changes:
- Set remove_done to TRUE.
- Data about the features recognized is now inaccessible. Data about recognized features which were not removed (other than those with faces on the kept faces list) is now accessible through the get_num_failed_features and get_failed_feature methods of the options object.
- The appropriate features are removed from the body.
- The options object remains in a state in which changing feature recognition parameters is not allowed.
- Present information to your end user about any failed features, allowing your end user to proceed to a customer-supplied "fall back" workflow for removing these features.
Note that the options object is always in one of three states, based on whether it has been used to recognize and/or remove features. Before feature recognition has been performed, you may change the feature recognition parameters, but querying for the features which have been recognized or have failed results in an error. After performing feature recognition but before feature removal, these parameters are fixed and cannot be changed. However, information about recognized features is available (information about failed features remains unavailable). After feature removal, the parameters remain fixed, and information about recognized features is again unavailable (because the faces in the features no longer exist). Information about failed features is available. The clear_features method resets the options object back to the first, pre-recognize, state. Copying or cloning the options object results in a new options object with the same feature recognition parameter information and kept face list as the original, but with its state reset back to the pre-recognize state. Thus, a "default override" options object can be kept by code for your use as a template for calls to feature recognition with non-standard defaults. However, the only information that this object should be used for is maintaining information you have provided such as feature recognition parameters and the kept face list.
The two workflows described above represent two ends of a spectrum of complexity with which you can use ACIS Defeaturing. You may choose to omit certain portions of the second workflow to produce a workflow that is at the appropriate level of complexity for your application.
Default Parameter Settings
Refer to the following table for the default value of each parameter in the defeature_options object:
| Parameter | Default Value |
|---|---|
| pause_after_recognize | FALSE |
| recognize_blends | TRUE |
| blend_max_radius | 10.000000 |
| blend_num_curvature_samples | 1 |
| recognize_chamfers | TRUE |
| cham_max_width | 10.0000 |
| recognize_holes | TRUE |
| hole_max_dia | 10.000000 |
| include_spherical_holes | TRUE |
Flowchart for Workflow
Permitted Operations
| State of defeature_options Object | Permitted Calls |
|---|---|
| Before Feature Recognition | Set different parameters on the defeature_options object. Set pause_after_recognize to TRUE or FALSE. Set the faces to be kept. |
| After feature recognition and before feature removal | Query the defeature_options object for the number of recognized features, type of recognized features, and the recognized features. Set the faces to be kept. |
| After feature removal | Query the defeature_options object for the number of failed features, type of failed features, and the failed features that could not be removed. |
Error Reporting
The interface to the ACIS Defeaturing Component obeys a "no-throw" contract; neither the API functions nor the methods of the options object may throw C++ exceptions. In most cases, error conditions are signaled by returning an ACIS outcome object; the exception to this is the get_num_features and get_num_failed_features methods of the options object, which return -1 when called inappropriately.
Scheme Interface
The workflow in Scheme remains the same as described above for the API: you may either use the default defeature_options parameters and make a single call to the Defeaturing component, or use a custom defeature_options object for a more interactive approach.
The defeaturing API call is wrapped by the body:defeature scheme command. All calls to manipulate and work with the defeaturing options object are wrapped under the scheme commands (defeature:xxxx).
The types of features that can be removed are holes, blends, and chamfers. The parameters in the defeature_options object control the removal of these features. For example, if you want to remove blends only, then set the recognize_holes and recognize_chamfers parameters to #f. Furthermore, you may set the blend_max_radius parameter to the appropriate value to control the blends that are to be removed. Similarly, you can control the behavior of the hole and chamfer removal by setting the appropriate parameters on the defeature_options object. Refer to the Defeaturing scheme commands for more details.
Related topics:
Types of Local Operations
Topology
Adaptive Offset
Body Repair
Blended Faces
Remove Faces
Limitations
[Top]
© 1989-2007 Spatial Corp., a Dassault Systèmes company. All rights reserved.