Difference between revisions of "2008 Winter Project Week:UnstructuredGrids"
Line 5: | Line 5: | ||
+ | Return to [[2008_Winter_Project_Week]] | ||
__NOTOC__ | __NOTOC__ |
Revision as of 14:40, 17 January 2008
Home < 2008 Winter Project Week:UnstructuredGrids
Return to 2008_Winter_Project_Week
Key Investigators
- Curt, Alex, Steve, Will, Vince, Bob O'Bara
Objective
The Slicer3 infrastructure is being extended to support Unstructured Grid datatypes for meshing processes, and the functions from the Univ. of Iowa workflow are being incorporated incrementally during the course of this project.
Approach, Plan
Unstructured grid node types are now supported in MRML. The external collaboration for Finite Element meshing is creating subclasses of these MRML nodes to store bounding box and FE mesh data. This work is a continuation of this project:
2007 Project Week - Support for Unstructured Grids
The main discussion points in this project are how the rendering of unstructured grids should be handled. Unstructured grids could be added for different purposes and rendered in different ways according to future Modules' needs. Our current design specifies each module should create its own subclasses of vtkMRMLUnstructuredGrid nodes and their corresponding display nodes, so rendering attributes could be accessed through the corresponding MRML display node.
Progress
During the January 2008 Project Week week, we successfully added MRML Display and Storage Nodes for FE mesh surface datatypes. A screenshot of a bone surface at right is generated from observing the MRML tree, instead of directly using actors in the slicer viewer, as we previously were doing. This is the correct long-term solution because the dataset view can now be transformable and editable through the MRML interface as standard Slicer objects.
vtkMRMLUnstructuredGrid subclasses are working stored in the MRML tree. This is the precursor to adding high-quality mesh rendering through alternate MRML display nodes.
Bob O'bara from Kitware was helpful with Mesh modification algorithms and explaining/debugging low-level VTK behaviors to members in our team. It was good to hear that VTK will have a rigorous meshing datatype in the future, as Bob develops this capability.