 |
Attributes |
Attributes
| <<< Attribute Definitions | Chapters | Introduction to Rendering and Faceting >>> |
The following types of information can be stored in fields (the corresponding field type is shown in brackets):
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):
|
Refer to the "User fields" section in Chapter 58, "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.
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.
| Write into a field | Read a whole field | Read the n'th entity in a field |
|---|---|---|
The following functions let you write into or read from a named field. You should not use these functions on non-named fields.
| Write into a named field | Read a whole named field |
|---|---|
For more information on creating attribute definitions with named fields, see Section 46.2.1, "Using named fields".
| Function | Description |
|---|---|
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 46, "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:
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 behavior 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 behavior 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 behavior 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 57, "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 if the attributes are equal, or they may all be kept. The effect depends on whether the class of attribute allows multiple copies, 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 behavior. For a description of each of the attribute definition classes listed below, see Section 46.2.4, "Classes of attributes".
| Class | Event | Effect on Attributes |
|---|---|---|
| 1 |
Reflection, Rotation, Translation, Scaling, Transfer, Change |
|
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 |
Reflection, Rotation, Translation, Scaling, Transfer, Change |
|
| 7 | ||
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 and surfaces) 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, i.e. points, curves and surfaces, 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, e.g. vertex, edge or face respectively. 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 | Introduction to Rendering and Faceting >>> |