Merge Regions And Scenes

Proposal: Merge Region and Scene hierarchies

The scene hierarchy (actually any given Scene, most commonly default) is only synchronized one level deep with the region hierarchy. Synchronizing any deeper is problematic because each hierarchy has different building blocks, and a 1:1 correspondence cannot be assured since we may need to add additional objects into the scene hierarchy to create the desired graphics.

Ignoring the complexity of maintaining synchronization, I expect users would only be confused if their model ever differed in structure from the hierarchy shown in the scene editor. When the average user selects graphical element heart in the scene editor they surely consider they are selecting the region heart, not just a graphical rendition of it.

The following outlines a proposal to merge the two hierarchies to create a clear central data structure for Cmgui, while maintaining the ability to create multiple, arbitrary graphical views and migrating concepts such as the overlay scene.

Central to the plan is that a region can contain multiple representations: the finite element field representation and its graphical rendition can coexist in the same Cmiss_region object, as can other representations and attributes. It is also intended that we can reference the same representation, with the same or different renditions from more than one region path. In a modelling sense these shared references may only serve as an alternative place to find the data (perhaps a different ontology/classification), but to the graphics system the region may be rendered more than once for such multiple instances; subject to different transformations and visibility controls.

Hierarchical Data Structures

Since neither the scene nor region hierarchies have been deeply exploited, we are still able to review and change our basic hierarchical data structures, within reason.

Hierarchies differ on where content can be kept:

1. All content is at leaf nodes (used by scene hierarchy)
2. All nodes able to have content AND children (used by region hierarchy).

I propose we adopt Option 2, as it allows model data to be stored by a common parent if that is logical (as a minimum, it could be field data for animating the transformation), and if it is not used it defaults to option 1. Option 1 also annoyingly requires two tree levels to add a child region, but on the slightly positive side this provides a logical place to control visibility of an entire sub-tree without clearing visibility flags through all children.

Hierarchies differ on how instances of child nodes are structured, allowing some to support assembly instances:

1. Child nodes are wrapped in a second object containing parent-specific name, selection state, visibility, transformation etc. (used by scene and region hierarchies; wrapping object is respectively Scene_object and Cmiss_region_child).
2. Parent and child nodes are the same class, each a unique instance, and have their own name, selection state, visibility and transformation relative to their single parent.

Option 1 allows sub-assemblies to be instanced multiple times in the hierarchy, e.g. 4 wheel assemblies in a car. Each assembly instance would have the same graphical rendition (I considered having multiple, named renditions stored in them and enabled by instance, but it looks too complicated). Option 1 has a neat separation of concepts that are only with respect to the parent, such as transformation. On the negative side the implementation requires another object, but its most damning attribute is that it is not possible to have a pointer to an instance in the hierarchy: the full path is needed to identify a unique instance of a region.

Option 2 is far simpler. It does not support assembly instances, but as a result a pointer to a hierarchy node (e.g. a Cmiss_region) is sufficient to identify the full path to the instance.

As mentioned above, we are free to share the representation (e.g. FE_region) and rendition between regions, or share the representation with a different rendition. Option 2 is therefore able to offer shallow copies of assemblies and single regions, the only difference is that the hierarchies are not synchronized with each other if one is modified.

Instancing is more suited to regular, man-made structures than bodies, and similarities in initial geometry will not generally extend to fields after computation. In Cmgui I see the main requirement is to be able to create a second visualization of a region, or assembly of regions to make a special graphic for post processing.

I propose we choose the simple Option 2 and remove Cmiss_region_child.

Multiple Hierarchies

The requirement to allow multiple, arbitrary graphical renditions in Cmgui implies we can build any number of hierarchies for separate display.

It is proposed that we achieve this by allowing Scene_viewers to display any part of the overall hierarchy, and require disciplined use of sub-regions as separate modelling hierarchies.

To establish this discipline, we will create an initial sub-region called default and make this the default location for models and graphics to be loaded, and the default model hierarchy for graphics windows to display. This is analogous to scene default in older commands, and this mapping is exactly how we will handle migration of most commands with a scene option.

Graphical Renditions

The graphical rendition object, attached to a region, combines:

1. Instance-specific data including visibility flag, transformation matrix, link to Cmiss_region instance and its selection object; perhaps its own time object/field.
2. Graphical settings, essentially our current graphical element.
3. Graphics objects, created from the above.

In the initial implementation all the above will be separate objects in each region instance. Eventually we want to allow the graphical settings to be sharable or otherwise propagated down a hierarchy, to allow renditions of whole hierarchies to be easily controlled (e.g. consider changing the surface colour of all bones in the skeleton). For regions containing the same finite element representation and the same graphical settings, we may also share graphics objects and display lists, but there are issues of highlighting these differently when some region instances are selected and some are not.

As with selection objects, rendition objects will track region changes and add renditions to new child regions, thereby filling the hierarchy.

Q & A

17. How do we draw simple graphics objects?

A Cmiss_region can contain a graphics object as its representation/rendition, giving us a migration path for all "gfx draw" commands.

We can also/alternatively consider adding a new settings type "object" allowing a simple GT_object to be output in the list of settings for visualizing a region. This seems an appropriate place to put graphics such as the axes, which pertain to the region. However, we generally won't want axes to appear in all regions sharing the same settings list, so more thought is needed here.

17. How to support default renditions (= lines) in future?

We can base it on the rendition of the parent region. The default region rendition may have "lines material default", which is copied to any new child region. The setting would have to be invisible in the default region and made visible in the new child. Perhaps an "inherited" flag is needed?

17. Can we independently control the visibility of a region and its hierarchy?

Visibility is like selection and applies to the immediate rendition only, not children. The required functionality is instead offered via a hierarchical visibility change operation, which may be available from a right-click context menu, or ctrl-clicking the visibility checkbox.

17. Should we make the transformation a separate object?

As long as the transformation is only used for graphics, a 4x4 matrix in the rendition object is sufficient and appropriate.

If we are required to have transformations and mappings for finite element fields (on a per-region basis), then a separate transformation object may be considered, but we will leave this issue to later discussions of FieldML. Hopefully computed fields can take care of most specialized field transformations.

17. Should region names be unique within parent?

CAD formats do not insist names are unique (6 wheel nuts can all be called nut), and identifying them uniquely would only require the addition of an instance number, which is not needed at all for interactive selection. I propose we keep unique names until we need otherwise.

17. Are groups (subsets of FE_regions) always children of master region?

No. It is advisable to follow this convention where possible, but we can't enforce it. To group objects from different regions requires a group of groups, and these won't necessarily be descendants of any or all contributing regions.

17. Can we support other representations in a region?

No reason why not. I am particularly interested in the idea of storing textures in regions since they are a kind of field. Perhaps they could be stored (by default) under a sub-hierarchy called texture. They could have special rendition objects for display in a graphics window.

17. What happens when reading in .exnode and .exelem files?

As now we will support them being read into a master region, with the groups put in child regions. The default master region will now be called default; it will no longer be the root_region. We should consider adding an option for groups to be read as true regions from these files.

17. How do we migrate existing commands involving scene name.

The name is prefixed as the first part of a region path. Creating a scene can create a region, perhaps with a warning message indicating the command is obsolescent. Drawing one scene in another can create a shallow copy of the hierarchy.

17. How do we support overlay scenes?

These are just additional region hierarchies. The graphics window / scene viewer need to be able to display a main region hierarchy and an overlay region hierarchy.

Feedback

Please add any feedback here.