Candidate RenderView modes for AttributeViews

One of the features in the nascent Task functionality is the ability to set the visualization options for RenderView widgets based on the current attribute editing situation. To help guide that development, this page enumerates the strawman feature set for the 2 most common cases: (i) assigning attributes to surface entities, such as boundary conditions, and (ii) assigning attributes to volume elements, such as material properties.

The tables below use the following symbols:

✔️ enabled (forced on and user may not edit)
✖️ disabled (forced off and user may not edit)
✏️ user editable
⚙(default) configurable preference with the given default

Assigning Attributes to Surface Entities

In most cases, the visualization features are applied to surfaces based on their relation to the association widget in the attribute view. The relations can include

  • Surfaces assigned to any attribute in the view
  • Surfaces assigned to the currently-selected attribute in the view
  • Surfaces not assigned but are in the available set for the view
  • Surfaces not available/allowed to be assigned to attributes in the view

Color faces based on attribute type: For a heat transfer example, we might have a base BC attribute definition with 3 derived definitions for (i) Heat Flux , (ii) HTC, and (iii) Dirichlet. The task configuration assigns one color to each derived definition. Unassigned surfaces (those which have no associated attribute but could be assigned the base BC definition) are assigned a fourth, user-configurable color.

Table 1. Color faces based on their attribute type.
Geometry Visible Representation Color Opacity Pickability
Volumes ✖️ ✖️
Assigned surfaces ✔️ surface 1 color per attribute type 0.5 ✔️
Unassigned surfaces ✔️ surface ⚙(white) 1.0 ✔️
Other surfaces ✏️ wireframe ⚙(white) 0.3 ✖️
Edges, vertices ✏️ ✏️ ✏️ ✏️ ✖️

Show unassigned surfaces: In this case, all unassigned surface are displayed with their default color (in the model resource). Other model faces are displayed in wireframe with some neutral color.

Table 2. Show unassigned surfaces.
Geometry Visible Representation Color Opacity Pickability
Volumes ✖️ ✖️
Assigned surfaces ✔️ wireframe ⚙(white) 0.5 ✖️
Unassigned surfaces ✔️ surface default 1.0 ✔️
Other surfaces ✔️ wireframe ⚙(white) 0.5 ✖️
Edges, vertices ✏️ ✏️ ✏️ ✖️

Color by value of designated subtype and child item: In this case, the assigned surfaces for one designated attribute type are displayed and are colored by the value of a designated item owned by that attribute. Using the heat transfer example, one option would be to display all surfaces with Dirichlet attributes in surface mode and all other surfaces in wireframe, and color the Dirichlet surfaces based on the value of the attribute’s “temperature” item. If the item uses an expression, it can be displayed in a neutral color, or better still, in a color pattern.

Table 3. Color by value of designated subtype and attribute child-item.
Geometry Visible Representation Color Opacity Pickability
Volumes ✖️ ✖️
Assigned surfaces ✔️ surface item value mapped through colormap 1.0 ✔️
Unassigned surfaces ✔️ wireframe ⚙(white) 1.0 ✔️
Other surfaces ✖️ ✖️
Edges, vertices ✏️ ✏️ ✏️ ✏️ ✖️

Color by designated item value vs. expression: The assigned surfaces are colored depending on whether a designated child item is set to a value or an expression. For heat transfer again, the designated item for Heat Flux attributes is “flux”; the designated item for HTC is “coefficient”, and the designated item for Dirichlet is “temperature”. If a texture or pattern can be used to indicate expression vs value, that would probably be much better than color.

Table 4. Color by designated item value vs. expression.
Geometry Visible Representation Color Opacity Pickability
Volumes ✖️ ✖️
Assigned surfaces ✔️ surface value color ⚙ or expression color ⚙ 0.5 ✔️
Unassigned surfaces ✔️ surface ⚙(white) 1.0 ✔️
Other surfaces ✖️ ✖️
Edges, vertices ✏️ ✏️ ✏️ ✏️ ✖️

Color by evaluating expression: I am not sure this belongs as a persistent visualization feature, but in some cases it could be interesting to colormap a surface by evaluating a designated item (e.g., temperature) over the surface. But this might instead be a runtime feature that can be applied ad hoc.

Table 5. Color by evaluating expression.
Geometry Visible Representation Color Opacity Pickability
Volumes ✖️ ✖️
Assigned surfaces ✔️ surface per-cell or per-vertex color mapped from evaluated expression 0.5 ✔️
Unassigned surfaces ✔️ surface ⚙(white) 0.3 ✔️
Other surfaces ✖️ ✖️
Edges, vertices ✏️ ✏️ ✏️ ✏️ ✖️

Assigning Attributes to Volume Entities

Todo

@johnt For the “Color faces based on attribute type” use case, can we generalize and say that some attribute definitions will be assigned colors and the most specific definition wins? The exact mapping of definition to color could be included in the task/view configuration.

Sure. We could assign a color to the base attribute type and optionally assign different colors to its subtype.

@johnt OK, I’ve updated the entry (and added tables for the other existing entries). I also took the liberty of making “other surfaces” somewhat user-editable since they may provide context.