Shape Attributes

A topological attribute can be seen as a hook into the topological structure. To this hook, data can be attached and references defined.

It is used for keeping and access to topological objects and their evolution. All topological objects are stored in the one user-protected TNaming_UsedShapes attribute at the root label of the data framework. This attribute contains map with all topological shapes, used in this document.

To all other labels TNaming_NamedShape attribute can be added. This attribute contains references (hooks) to shapes from the TNaming_UsedShapes attribute and evolution of these shapes. TNaming_NamedShape attribute contains a set of pairs of hooks: old shape and new shape (see the figure below). It allows not only get the topological shapes by the labels, but also trace evolution of the shapes and correctly resolve dependent shapes by the changed one.

If shape is just-created, then the old shape for accorded named shape is an empty shape. If a shape is deleted, then the new shape in this named shape is empty.

### Shape attributes in data framework.

Different algorithms may dispose sub-shapes of the result shape at the individual label depending on necessity:

- If a sub-shape must have some extra attributes (material of each face or color of each edge). In this case a specific sub-shape is placed to the separate label (usually, sub-label of the result shape label) with all attributes of this sub-shape.

- If topological naming is needed, a necessary and sufficient (for selected sub-shapes identification) set of sub-shapes is placed to the child labels of the result shape label. As usual, as far as basic solids and closed shells are concerned, all faces of the shape are disposed. Edges and vertices sub-shapes can be identified as intersection of contiguous faces. Modified/generated shapes may be placed to one named shape and identified as this named shape and source named shape that also can be identified with used algorithms.

TNaming_NamedShape may contain a few pairs of hooks with the same evolution. In this case topology shape, which belongs to the named shape, is a compound of new shapes.

The data model contains both the topology and the hooks, and functions handle both topological entities and hooks. Consider the case of a box function, which creates a solid with six faces and six hooks. Each hook is attached to a face. If you want, you can also have this function create hooks for edges and vertices as well as for faces. For the sake of simplicity though, let's limit the example.

Not all functions can define explicit hooks for all topological entities they create, but all topological entities can be turned into hooks when necessary. This is where topological naming is necessary.

Consider the following example. A box defines six hooks for the six faces, but a protrusion created on a face of the box can only define two hooks, one for the top face, and one for all the lateral faces. As the basic wire defining the protrusion may change in the future the protrusion function cannot designate the lateral faces without ambiguity, their number may change. Figure 6 illustrates this example, faces F1 to F6 of the box each have a hook. Faces F7 to F10, the lateral faces of the protrusion, share a single hook, and face F11, the top face, has one hook.

A box

This structure raises two problems:

- the value of the face F6 attribute-hook has changed

- no data can be attached to F7.

When a hook designates multiple faces like F7-F10 (or the hook on F6 if F6 was split) it is impossible to attach data to an individual face like F7.

In fact, the protrusion has a trimmed face F6. As a result, the value of this face has changed and the current value of the hook attached to it needs to be found. Note that this face could have been split in two faces (for example if the function had been a slot) and both new faces would have been attached to the same hook.

For information on the relations between this component of OCAF as well as other ones, refer to the OCAF User's Guide.