Difference between revisions of "2008 Winter Project Week:UnstructuredGrids"

From NAMIC Wiki
Jump to: navigation, search
(initial edit)
 
 
(18 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{|
 
{|
|[[Image:NAMIC-SLC.jpg|thumb|320px|Return to [[2008_Winter_Project_Week]] ]]
+
|valign="top"|[[Image:slicer-uneditable-bbox.jpg |thumb|320px|FE Module Prototype in Slicer3 (using actors)]]
|valign="top"|[[Image:slicer-uneditable-bbox.jpg |thumb|320px|FE Module Prototype in Slicer3]]
+
|[[Image:MeshingDisplayNode.png |thumb|320px|"New" Display generated from MRML Display Node]]
 
|}
 
|}
 +
 +
 +
Return to [[2008_Winter_Project_Week]]
  
 
__NOTOC__
 
__NOTOC__
Line 14: Line 17:
  
 
<h1>Objective</h1>
 
<h1>Objective</h1>
Several different module developers have asked  to insert and operate with VTK-style 3D widgets in the Slicer 3D view window.  This project will study the implications of different ways to insert 3D widgets and how the design of VTK 3D widgets can best interact with Slicer's MRML tree.  Widget interaction may require an extension to the MRML observer paradigm. 
 
 
 
    
 
    
 
 
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.  
 
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.  
  
Line 25: Line 25:
  
 
<h1>Approach, Plan </h1>
 
<h1>Approach, Plan </h1>
The Univ. of Iowa Finite Element collaboration project has added 3D widgets using direct manipulation and custom callbacks.   We will discuss the strengths and weaknesses of this approach as a case study.
+
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:
 +
 
 +
[http://www.na-mic.org/Wiki/index.php/Projects/Slicer3/2007_Project_Week_Support_for_Unstructured_Grids 2007 Project Week - Support for Unstructured Grids]<br>
  
At the end of the week, our objective is to have additional clarity on the design approach that modules should take when they want to interact with 3D widgets in Slicer3.  
+
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.  
 
   
 
   
 
</div>
 
</div>
Line 34: Line 36:
  
 
<h1>Progress</h1>
 
<h1>Progress</h1>
 +
====Jan 2008 Project Week====
 +
We successfully added MRML Display and Storage Nodes for FE mesh surface datatypes (which are subclasses of the VTK Unstructured Grid datatype.)  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 mesh quality rendering (similar to the standalone mesh quality viewer) using 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. 
  
 
</div>
 
</div>

Latest revision as of 15:41, 6 February 2008

Home < 2008 Winter Project Week:UnstructuredGrids
FE Module Prototype in Slicer3 (using actors)
"New" Display generated from MRML Display Node


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

Jan 2008 Project Week

We successfully added MRML Display and Storage Nodes for FE mesh surface datatypes (which are subclasses of the VTK Unstructured Grid datatype.) 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 mesh quality rendering (similar to the standalone mesh quality viewer) using 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.