concepts.rst 4.23 KB
Newer Older
1 2 3
Key Concepts
============

4
Like the attribute resource, the model system is composed of C++ classes,
5 6
also accessible in Python, whose instances perform the following functions:

7
:smtk:`Resource <smtk::model::Resource>`
8
  instances contain model topology and geometry.
9 10
  All of the model entities such as faces, edges, and vertices are
  assigned a UUID by SMTK.
11
  You can think of the resource as a key-value store from UUID values to
12
  model entities, their properties, their arrangement with other entities,
13
  their ties to the attribute resource, and their tessellations.
14

15
:smtk:`Session <smtk::model::Session>`
16 17
  instances relate entries in a model Resource to a solid modeling kernel.
  You can think of the entities in a model Resource as being "backed" by
18
  a solid modeling kernel; the session provides a way to synchronize
19 20
  the representations in the Resource and the modeling kernel.

21 22 23 24 25

:smtk:`Operator <smtk::model::Operator>`
  instances represent modeling operations that a modeling kernel
  provides for marking up, modifying, or even generating modeling entities
  from scratch.
26
  Operators usually require the entries in the model Resource to be
27 28
  updated after they are executed (in the solid modeling kernel).
  Each operator implements a method to invoke its operation in the modeling kernel
29
  and owns an attribute resource Attribute instance (its *specification*) to store
30 31
  the parameters required by the operation.
  SMTK expects the primary operand of an operator (e.g., a set of edge entities
32
  in the model resource to be swept into a face) to be model entities
33 34 35 36
  **associated** with the operator's specification.
  Other operands (e.g., the geometric path along which to sweep a set of edges)
  are stored as key-value Items in the specification.

37
:smtk:`EntityRef <smtk::model::EntityRef>`
38
  instances are lightweight references into a model Resource's storage
39 40 41
  that represent a single entity (e.g., a vertex, edge, face, or volume)
  and provide methods for easily accessing related entities, properties,
  tessellation data, and attributes associated with that entity.
42
  They also provide methods for manipulating the model Resource's storage
43
  but *these methods should not be used directly*; instead use an Operator
44
  instance to modify the model so that the modeling kernel and model resource
45
  stay in sync.
46 47
  EntityRef subclasses include Vertex, Edge, Face, Volume, Model,
  Group, UseEntity, Loop, Shell, and so on. These are discussed
48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71
  in detail in `Model Entities`_ below.

:smtk:`DescriptivePhrase <smtk::model::DescriptivePhrase>`
  instances provide a uniform way to present model entities and the information
  associated with those entities to users.
  There are several subclasses of this class that present an entity,
  a set of entities, an entity's property, and a set of entity properties.
  Each phrase may have 1 parent and multiple children;
  thus, phrases can be arranged into a tree structure.

:smtk:`SubphraseGenerator <smtk::model::SubphraseGenerator>`
  instances accept a DescriptivePhrase instance and enumerate its children.
  This functionality is separated from the DescriptivePhrase class so that
  different user-interface components can use the same set of phrases but
  arrange them in different ways.
  For example, a model-overview widget might subclass the subphrase generator
  to only enumerate sub-models and sub-groups of the entity in its input
  DescriptivePhrase; while a model-detail widget might include volumes, faces,
  edges, and vertices when passed a DescriptivePhrase for a model.


Model Entities
==============

72
As mentioned above, the model :smtk:`Resource <smtk::model::Resource>` class
73 74
is the only place where model topology and geometry are stored in SMTK.
However, there are EntityRef-like classes, all derived from :smtk:`smtk::model::EntityRef`,
75 76 77
that provide easier access to model traversal.
These classes are organized like so:

78
.. findfigure:: entityref-classes-with-inheritance.*
79

80
   Each of the orange, green, purple, and red words is the name of an EntityRef subclass.
81 82 83 84
   The black arrows show relationships between instances of them (for which the
   classes at both ends provide accessors).

Each relationship shown in the figure above has a corresponding
85
method in the EntityRef subclasses for accessing the related entities.