SMTK 22.04 Release Notes¶
See also SMTK 22.02 Release Notes for previous changes.
SMTK Common Changes¶
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
Short alternative |
Formal alternative |
📦 |
Purpose |
---|---|---|---|
|
|
A coordinate frame relative to another component (or if none given, the world). |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
📦 |
A point of interest that also has directions of interest. |
|
|
📦 |
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. |
|
|
📦 |
An (o)riented (b)ounding (b)ox – non-unit-length vectors, but orthogonal. Axis lengths indicate bounds along each axis. |
|
|
📦 |
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. |
|
|
📦 |
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. |
|
|
📦 |
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.
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.