|
Depending on the modeling operation, input entities may or may not exist after an operation is complete. For example, blending operations typically remove vertices and edges and add new entities.
|
|
|
When such input entities no longer exist, they are still represented with an
ATTRIB_TAG which contains a pointer to the original input entity and a flag indicating whether or not the entity has since been lost.
ATTRIB_TAG is a base class that can be derived from and enhanced by a user-defined application. An application can use this to attach additional data to the input entities before an operation and have it carried forward to any annotations that reference it, even if the original entity is lost.
|
|
|
ATTRIB_TAG is designed to be derived from, so the application may store additional information there. Annotations contain a copy of the tag. If the application has not already tagged an input entity, the annotation will construct
ATTRIB_TAGs as required. The utility functions
get_actual_entity and
get_actual_live_entity can simplify working with the tags.
|
|
|
Applications which derive from
ATTRIB_TAG may want to set the
error_no_input_tag option to
TRUE to cause a
sys_error if an input entity is not tagged. This is useful when the additional attribute information is necessary. It is also a useful debugging aid which helps to find places where the application did not tag all the inputs. If the
error_no_input_tag option is
FALSE, tags are simply generated on the fly as needed.
|
|
|
During the operation, annotations are attached to the inputs and outputs via
ATTRIB_ANNOTATION. This attribute serves to pass on attribute notifications to the actual annotations and to let any copied
ATTRIB_TAGs know if the input entity has been lost. They may optionally be kept after the operation as well. This is used in Scheme to support display of annotation information. That is, you can pick some topology and follow the attribute to see how it fit in a recent operation.
|