| |
Attributes |
| <<< Attribute Definitions | Chapters | Partitions >>> |
Attributes are used to supplement the Parasolid data structure by attaching additional data to Parasolid entities. An attribute has properties, specified in an attribute definition, which define the:
The following types of information can be stored in fields (the corresponding field type is shown in brackets):
|
Note: Attributes cannot be attached to orphan geometry regardless of the entity class. |
|
Note: Fields of type PK_ATTRIB_field_pointer_c do not get stored in the Parasolid part during PK_PART_transmit. They are transmitted as empty fields and so their contents will not appear on the model after PK_PART_receive. |
An attribute is created by specifying the attribute definition and the entity to which it is attached. The attribute can only be attached to entities of the classes specified in its attribute definition. At this stage the attribute fields are empty.
Each field of the attribute can then be set and enquired, and each field can hold any number of items of data of the appropriate type (except string fields, which can only hold a single string):
For an example of this functionality, see the code example in the
C++\Code Examples\Application
Support\Attribute
Processing\Attributes
folder, located in
example_applications
in your Parasolid installation folder.
|
Refer to the “User fields” section in Chapter 115, “Session Support”, for a comparison of attributes and user fields. |
PK_ATTRIB_create_empty is used to create a new attribute. This is attached to the specified entity (as given by PK_ATTRIB_ask_owner) and has the given attribute definition (PK_ATTRIB_ask_attdef), but does not contain any data.
Creating an empty attribute and attaching it is considered only the first stage in associating a valid attribute with an entity. The second stage is to populate that attribute with suitable information. A model with empty attributes associated with any of its entities is considered to be in an intermediate state, and should not be used for further modelling operations.
You can check the validity of an attribute, either as part of a more general check of a group of entities or as a specific check of the attributes attached to a given entity. See Section 30.2.3, “Checking system attributes”, for more information.
A number of functions are available to write an array of data into an attribute field of a given type, and to retrieve that data. The functions that you need to use depend on whether the attribute uses named or numbered (i.e. non-named) fields.
The following functions let you write into or read from a numbered field. These functions can also be used on named fields, provided you know the order in which the fields are defined in the attribute definition.
The following functions let you write into or read from a named field. You should not use these functions on non-named fields.
For more information on creating attribute definitions with named fields, see Section 94.2.1, “Using named fields”.
|
Delete attributes of specified attribute definitions from all the entities, or from all sub-entities of a certain class, in a part. |
|
Return selected attributes and their owners, using a callback function to select attributes. See Section 95.2.6. |
|
|
Return the entities of a body with or without a particular attribute |
The most flexible way of enquiring about the attributes on a part, together with the entities those attributes are attached to, is to use PK_PART_ask_attribs_cb. This function lets you specify a callback function in your application code that can be used to return selected attributes in a part, based on their attribute definitions and the field values of the attributes themselves. PK_PART_ask_attribs_cb takes the following arguments:
n_attribs,attribs |
The attributes in |
Any callback function you define must take as its arguments the standard form for an attribute definition, together with the arrays of attribute field values and their lengths, and any context that is specified in the call to PK_PART_ask_attribs_cb. As an example, the following code demonstrates how you could define a callback function that returns an attribute if its field value is equal to a specified string. This code performs the following checks, which are necessary because every attribute on the part is examined:
PK_LOGICAL_t my_callback (const PK_ATTDEF_sf_2_t *attdef_sf, const int field_lengths[], const PK_ATTRIB_field_values_t field_values[], PK_POINTER_t context) { char *str = (char *) context; if (attdef_sf->n_fields > 0 && attdef_sf->field_types[0] == PK_ATTRIB_field_string_c && field_lengths[0] == strlen( str ) && strncmp( field_values[0].chars, str, field_lengths[0] ) == 0) return PK_LOGICAL_true; else return PK_LOGICAL_false; } |
The example uses
strncmp
rather than
strcmp
because string fields are not null-terminated.
A call to PK_PART_ask_attribs_cb that successfully returned an attribute with the correct field value might be as follows:
PK_PART_ask_attribs_cb( part, my_callback, "block", NULL, &n_attribs, &attribs, &owners ); |
Attributes can be moved between entities, modified, or deleted, as a result of modeling operations. The effects of these operations on an attribute first depend on whether the attribute definition has any normal callback functions registered.
In the case of normal callbacks, the callback function is invoked instead of the normal Parasolid attribute processing.
In the case of read-only callbacks, the callback function is invoked and Parasolid attributes are processed as normal.
Attribute callback functions are described in the “Callback functions” section in Chapter 94, “Attribute Definitions”.
If a callback function is not invoked, the normal Parasolid attribute processing is applied. The remainder of this chapter deals with this process, which depends on the:
You can think of high-level modeling operations (booleans, local operations, blending, etc.) as a succession of primitive modeling operations, or events, applied to individual entities. The behaviour of an attribute under a modeling operation is the composite of the elementary effects of those events that are applied to the entity to which it is attached.
The following section describes the events and what effects they may have on an attribute attached to a topological entity to which the operation is applied. The effects vary according to the class of the attribute’s definition, and whether attribute callbacks have been registered.
|
Note: These effects are not applied to attributes attached to geometrical entities. |
The detailed effects explained in this section are the result of the normal Parasolid attribute processing. However, some events may cause a callback function to be invoked instead.
When normal callbacks are registered for an attribute definition, these callback functions override the existing behaviour of an attribute, which is currently defined by the class of the attribute.
When read-only callbacks are registered for an attribute definition, then normal attribute processing takes place, and the read-only callback is invoked as well.
If callbacks are only registered for some of the events, then the behaviour of attributes during events that do not have callbacks registered continues to be defined by the attribute’s class.
To determine how attributes that are involved in modeling operations are affected by these operations, proceed as follows:
Chapter 99, “Bulletin Board”, explains how to log and output the events which have been applied to entities.
An entity may be transformed, in which case all the entities that the model regards as part of it (the surface of a face, the edges of a body etc.) are likewise transformed. The effects of a transformation depend on its decomposition into these four primitive transformation types:
Each type of transformation may independently be applied to, have no effect on, or cause deletion of, an attribute attached to the entity transformed.
When a transformation is applied to an attribute, it affects each field in a manner which depends on the field type; only the four geometric field types (vector, direction, coordinate and axis) are affected, and each of these transform differently. To determine the effect of a complex transformation it is necessary to decompose it into a combination of primitive transformations and look at their individual effects on the various field types, which are as follows:
A topological entity or a group may be copied, or be split into two or more entities of the same class. When an entity is split, each attribute on it is either deleted or propagated to both the resulting entities.
|
Note: This does not occur in blending as a new face is created, in preference to splitting adjacent faces, therefore there is no propagation. |
Alternatively, splitting an entity may invoke a callback function for attributes attached to it.
Two topological entities of the same class may be merged to form one. During a merge operation, an attribute with the same definition on each of the two entities may be deleted, or it may be kept. The behaviour depends on whether the class of attribute allows multiple copies, as follows:
Two attributes are considered equal if they have the same attribute definition and the same values in all fields (using the Parasolid session’s modeling resolution for linear and angular precision).
For more information on attribute classes, see Section 94.2.4, “Classes of attributes”.
Examples of merge operations are as follows:
Alternatively, merging an entity may invoke a callback function for attributes attached to it.
An entity may be transferred from one part to another, into a part or out of a part. For example, shells, faces, loops, etc., may be transferred between bodies during a boolean. Note that when geometry is transferred out of a part but not into another it ceases being a legitimate owner of attributes and so loses all its attributes. Other than this, transferring an entity may cause attributes attached to it to be deleted or left as they are.
An operation such as a boolean may have no effect on a face or edge except to transfer it from one part to another.
Entities may be created and deleted, either directly by a call to Parasolid requesting creation or deletion of the entity, or indirectly. For example, when a boolean is performed many entities may be created or deleted. A newly created entity (i.e. not split from an existing entity) has no attributes. Deletion of an entity deletes any attributes attached to it.
Alternatively, copying or deleting an entity may invoke a callback function for attributes attached to it.
An entity may be changed in some other way. The change event is, in effect, any change not expressible in terms of the other events. It either causes the attributes on the changed entity to be deleted or it has no effect on them.
Transmitting an entity may invoke a callback function for attributes attached to it.
Receiving an entity may invoke a callback function for attributes attached to it.
It should be noted that a change of face sense does not by itself induce an event - the attributes attached to a face are not affected if simply the face sense is reversed. However, the attributes are likely to be affected by the operation that caused the reversal.
Subtracting a cylindrical body from a block creates a cylindrical hole in the block with the sense of the cylindrical face reversed (in which case, attributes attached to the cylindrical face are affected as described in the section “Combining events” below).
The following table shows a summary of the normal processing which Parasolid applies to an attribute, when normal callbacks are switched off. If switched on, normal callbacks replace this behaviour. For a description of each of the attribute definition classes listed below, see Section 94.2.4, “Classes of attributes”.
|
Reflection, Rotation, Translation, Scaling, Transfer, Change |
||
|
Reflection, Rotation, Translation, Scaling, Transfer, Change |
||
For more information on the effects that events can have on attributes, see Section 95.4, “Events and how they affect attributes”.
Many high-level modeling operations result in multiple events being applied to entities affected by an operation. The effect on attributes attached to these entities is a combination of the effects of each event.
For example, if the following operations have any effect on a face or an edge, they do so as a combination of the split, transfer and change events:
These operations result in the deletion of attributes of class 2, 3 or 5 on the face or edge, while attributes of class 1, 4, 6 and 7 are preserved, and propagated to any new faces or edges split off from the original.
Attributes can be attached to geometric entities (points, curves, surfaces and lattices) which are themselves attached to topology (even if only as construction geometry). However, this is only permitted for attributes of class 1, 4, 6 and 7. Such attributes are only affected by deletion of the attribute or the geometry owning it, or by overwriting with a new attribute of the same definition. No other modeling operations affect an attribute attached to a geometric entity.
Geometric entities can only own attributes if they themselves are owned by a part, i.e. if they are either construction geometry for that particular part, or if they are the geometry of some corresponding topological entity in the part. Thus it is not possible to attach attributes to orphan geometry and if geometry with attributes attached to it is transferred out of a part but not into another, it loses its attributes.
The effect of modeling operations on attributes attached to a group depends on the classes of the entities in the group. There is a simple algorithm that can be used to determine the effect of a given modeling operation on an attribute attached to a group:
| <<< Attribute Definitions | Chapters | Partitions >>> |