SMTK 22.04 Release Notes

See also SMTK 22.02 Release Notes for previous changes.

SMTK Common Changes

Factory API for shared pointers

The smtk::common::Factory template now provides method names that begin with make and which return shared pointers (in addition to the create methods which return unique pointers).

This change was made to accommodate some compilers (e.g., gcc 11) that are unable to cast unique pointers with an explicit deleter into shared pointers.

SMTK QT Changes

Enable QT_NO_KEYWORDS builds

SMTK compile definitions now include QT_NO_KEYWORDS, which means all uses of emit, foreach, signals, and slots has been replaced with Q_EMIT, Q_FOREACH, Q_SIGNALS, and Q_SLOTS, and must be updated for any SMTK plugins that use the smtk_add_plugin cmake macro. This is to avoid conflicts with 3rd-party libraries, like TBB, which use the old keywords.

Added names to qt UI objects to allow for more repeatable automatic testing

Automated tests were not giving repeatable results due to unpredicatble Qt implicit naming of UI widgets. To avoid this, all UI widgets were manually assigned names using QObject::setObjectName()

Developer changes

It would be good to use QObject::setObjectName() for any new Items to avoid breaking this new “fully named” status.

User-facing changes

N/A

SMTK ParaView Extensions Changes

Added a Mechanism to hide labels for pqSMTKAttributeItemWidget

You can now suppress the item’s label from being displayed by simply setting the label value to be “ “ (note a single blank and not the empty string). As long as the item is not optional, its label will not be displayed.

3D Widget Visibility

3D widgets have an application-controlled setting that allows them to remain visible even if their Qt controls loose focus or are hidden. This overrides the ParaView default behavior of only allowing one 3D widget to be visible at a time.

Developer changes

By default, widget visibility behavior is not changed. To enable for an application, call pqSMTKAttributeItemWidget::setHideWidgetWhenInactive(false); on startup

User-facing changes

When this setting is enabled, multiple 3D widgets can appear in a renderview. Widgets that might overlap need a user control to hide the widget, to allow easier interaction. The last widget to be shown will receive precendence for mouse and keyboard events.

SMTK Representation Changes

The ParaView representation now renders components with coordinate-frame transforms applied. This is implemented using a new vtkApplyTransforms filter; for resources without any transforms, this simplifies to an inexpensive copy of the input blocks. When transforms exists, VTK’s vtkTransformFilter is used which can be expensive for large geometry. In the future, this cost may be avoided using a custom mapper.

Added the Ability to Render Geometry with Solid Cells

  • vtkResourceMultiBlockSource will now put Components with Solid Cells under its component Component Block

  • vtkApplyTransfors will now also do a surface extraction for components with solid cells

SMTK Project Changes

Made projects portable between different file systems and paths

Changed absolute file paths used in the project relative paths where necessary to allow the project folder to moved to a new location, or even another machine.

Developer changes

No new absolute paths should be added to the project. Any new paths that are saved should be saved as relative to the project main folder. Ideally, all files and folders that are part of a project should be contained within the main project folder.

User-facing changes

With this change in plase, projects can be freely moved on a given machine, or shared to a completely new machine in a seemless fashion.

SMTK Resource Changes

Expanded SMTK Properties to include sets of ints

You can now create a property that is represented as a set of integers

Resource subclasses and the move constructor

Because smtk’s smtk::common::DerivedFrom template, used when inheriting Resource, declares a move constructor with the noexcept attribute, all subclasses of Resource must explicitly declare a move constructor with the noexcept attribute. Modern versions of clang are strict about checking this.

Improved smtk::resource::Metadata

The smtk::resource::Metadata class constructor now requires create, read, and write functors which take an smtk::common::Managers instance as input so that creating, reading, and writing resources can make use of any available application-provided manager objects.

If you had any resource subclasses that provided these functors, you must update to the new signature. This is a breaking change.

Be aware that the operation and operation manager classes now accept an smtk::common::Managers instance. If provided to the operation manager, all operations it creates will have the managers object set (for use by operations). This is the preferred way for applications to pass information to operations. Using this method allows operations to be used in several applications with minimal dependencies on application-specific methods and structures.

Finally, methods on the vtkSMSMTKWrapperProxy, vtkSMTKWrapper, and pqSMTKWrapper classes that returned a TypeContainer& have been deprecated in favor of methods that return smtk::common::Managers::Ptr so that operations can make use of the type-container’s contents without copy-constructing a new Managers instance.

Coordinate Frame Property

SMTK’s resource system now provides resources with a property to store coordinate frames (an origin plus 3 orthonormal vectors specifying a change of basis). Besides the change of basis, each frame also holds an optional UUID of a parent component. If present and the parent also holds a matching coordinate frame, the two transforms may be concatenated.

Because properties are named, coordinate frames may take on different roles. SMTK currently only deals with one role: when a coordinate frame is stored under the name transform or smtk.geometry.transform, it is taken to be a transformation that should be applied to its associated component. If the parent is unspecified, the coordinate frame transforms the component’s geometry into world coordinates. If a parent is specified, then it transforms the component’s geometry into its parent’s coordinates (which may or may not be further transformed).

Future alternative uses for coordinate frames include

Coordinate frame property names

Short alternative

Formal alternative

📦

Purpose

transform

smtk.geometry.transform

A coordinate frame relative to another component (or if none given, the world).

centroid

smtk.markup.centroid

The geometric center of a component. This may not always be identical to pca below if the component is defined as a surface discretization bounding a volume.

center

smtk.markup.center

The center of mass and principal axes (from computation of moments of inertia) that take a component’s volumetric density field into account. Because density is involved, this is not always identical to centroid. It is in some cases, such as if the density is uniform.

pca

smtk.geometry.pca

The results of (p)rincipal (c)omponents (a)nalysis on the component’s geometry. This is not always identical to centroid (when the component’s geometry is a boundary representation) or center (when density is not uniform). PCA may also include “robust PCA,” in which case it may warrant a distinct property name.

landmark

smtk.markup.landmark

📦

A point of interest that also has directions of interest.

datum

smtk.markup.datum

📦

A coordinate system used as a reference in analysis or geometry construction. This is distinct from landmarks, which are intrinsic features of geometry as opposed to datum frames used to construct geometry.

obb

smtk.geometry.obb

📦

An (o)riented (b)ounding (b)ox – non-unit-length vectors, but orthogonal. Axis lengths indicate bounds along each axis.

screw

smtk.geometry.screw

📦

Denavit–Hartenberg parameters for screw transforms. Either z-axis length indicates screw pitch (non-unit length) or an additional property or subclass would need be required for the screw pitch. Note that there is an alternate formulation of DH parameters called “modified DH parameters” which might deserve an additional distinct name.

criticality

smtk.markup.criticality

📦

The location and orientation of a vector-field criticality (such as a source, sink, or saddle point), perhaps with additional information in other properties such as the rotational components about each axis.

symmetry

smtk.geometry.symmetry

📦

A frame used to describe symmetric boundary conditions, solution periodicity, etc. Some extensions would be required to annotate more complex symmetries (cylindrical/spherical coordinate systems or n-way symmetry about an axis with n other than 2 or 4.

The table uses

  • smtk.geometry for formal names of properties that might conceivably interact with the geometric data layer in SMTK (i.e., change what is rendered) and

  • smtk.markup for formal names of properties that are annotations that might have illustrations but not affect the underlying geometric representation of the component itself.

  • The “📦” column indicates whether the property would be used to hold a single coordinate frame or a collection of some sort (a fixed-size array, variable-length vector, set, map, etc.).

SMTK Graph Session Changes

Graph Arcs now support inverse relationships

Arcs may implement inverse relationships via the Inverse handler to seamlessly add/remove arcs as coupled pairs.

Developer changes

Arc(s) Required APIs:
  • insert(ToType&,bool)

  • erase(ToType&,bool)

  • begin()

  • end()

  • Note, insert and erase take a second boolean argument that is used by the Inverse handler to break recursive insertion/removal of inverses.

The default behavior of operations for each type of arc type when inserted as the inverse are as follows.

Default Arc Type Inter-op

Self Arc Type

Inverse Arc Type

Assign

Insert

Erase

Arc

Arc

Overwrite self, remove current inverse, insert new inverse.

Insert inverse if valid to insert self, insert self if inverse successfully inserted.

Unset self and erase inverse.

Arc

Arcs

Overwrite self, remove current inverses, insert new inverse.

Insert inverse if valid to insert self, insert self if inverse successfully inserted.

Unset self and erase inverse.

Arcs

Arc

Overwrite self, remove current inverses, insert new inverses.

Insert self, if successful insert inverse, if inverse failed remove self and report failure

Erase inverse and self.

Arcs

Arcs

Overwrite self, remove current inverses, insert new inverses

Insert self, if successful insert inverse, if inverse failed remove self and report failure.

Erase inverse and self.

OrderedArcs

Arc

Overwrite self, remove current inverses, insert new inverses.

Insert inverse, if successful insert self.

Erase inverse and self.

OrderedArcs

Arcs

Overwrite self, remove current inverses, insert new inverses.

Insert inverse, if successful insert self.

Erase inverse and self.

Arc or Arcs

OrderedArcs

Throw std::logic_error exception.

Throw std::logic_error exception.

Erase self and first matching inverse.

OrderedArcs

OrderedArcs

Won’t compile.

Won’t compile.

Won’t compile.

All behaviors can be overwritten by providing a specialization of smtk::graph::Inverse.

User-facing changes

The user should not see any major changes. Management of arc types with an inverse is now handled automatically so there may be some improvements to arc consistency.

SMTK View Changes

Fix Editing Descriptive Phrase Titles

When editing the title of a Descriptive Phrase of a Resource using the QT UI, the user is presented with what was being displayed which included the Resource’s name as well as with Resource’s location (in the case of the Resource Panel) or the Resource’s Project role and name (in the case of the Project Panel).

If the user didn’t initially clear the title, the original title (including the role or location information) was set as the Resource’s new name instead of just the name component.

This has been corrected so that when editing the title, the user is only presented with the Resource’s name. When editing is completed, the location/role information will be added properly.

Plugin Changes

ParaView Plugins

SMTK’s ParaView appcomponents plugin has been split into 2 plugins and 2 new plugins have been added. Where previously the smtkPQComponentsPlugin held all functionality, the operation panel has been moved into smtkPQLegacyOperationsPlugin so that applications based on SMTK may exclude it. Likewise, the new operation toolbox and parameter-editor panels are in a new smtkPQOperationsPanelPlugin. Applications may include any combination of the operation-panel plugins.

Finally, a new ApplicationConfiguration interface-class has been provided. The toolbox panel waits to configure itself until an subclass instance is registered with ParaView, at which point it is queried for a view-information object. Use of this pattern is likely to expand in the future as panels add more flexibility to their configuration.