View source for Slicer Interactive Module

The scope of this subproject is to develop a Slicer3 module for Finite Element modeling.  Our approach is to adapt the process and source code from a standalone Finite Element Mesh generation program developed by the MIMX Group at the University of Iowa.   

== Standalone Program ==

The IaFeMesh application creates an established workflow consisting of multiple steps:

* read imagery file
* create surface from imagery
* create FE mesh bounding box from the bounds of the surface
* refine the FE bounding box
* generate a mesh using projection from the bounding box

The above properties are accomplished through customer KKWidgets which manage the user through workflow using a custom tabbed notebook with image, surface, FE Mesh, and FE Mesh Quality tabs.   Under each category, the user works with the corresponding category of data as they perform the workflow that starts with a source image stack and results in a corresponding Mesh of the imaged object.  

The standalone program manages surfaces, bounding boxes, and meshes created by the user in linked lists which are updated and displayed through a directly connected GUI.  


[[image:IaFeMesh-small-102507.jpg]]



== MeshingWorkflow Slicer Module ==

An interactive module has been added to Slicer called the "MeshingWorkflow Module".  This module performs the same multiple steps as the standalone FE application.  The vast majority of the source code from the original application has been re-used without modification.



[[image:slicer-meshingworkflow-small-102507.jpg]]


=== Migrating the intermediate steps to MRML === 

The standalone workflow code uses local lists of surfaces, bounding boxes, and meshes to store intermediate workflow state.  This allows the user to browse forward and backward through the workflow as needed and is an efficient workflow model.   A drawback of this technique (from the slicer integration perspective) is that this information is not stored in the MRML tree during the workflow process.

Therefore, modifications were required to the storage list classes to synchronize with the MRML tree.

=== Steps to Ingest standalone application code for a Slicer module===
* Adapt CMakeLists files from stand-alone to module versions.  Keep old module cmake configuration files as an example how to add proper wrapping and inter-library references.
* Debug support libraries (Common, Widgets, Adapter, Filter, BuildingBlock, etc.) one at a time until you have Compiled each supporting library separately.


=== Coding change notes for Slicer integration of standalone IaFeMesh source code ===
* Commented unneded functionality in BuildingBlock/vtkKWMimxMainWindow - we are using Slicer's 3D window instead and will set the renderWindowWidget after instantiation.
* Added vtkKWMimxMainWindow::SetRenderWidget()
* The Changes to the main and view windows makes the notebook more complicated.  This is less straightforward than the initial time, when the viewWindow was separate from the main Window.   KWMimxMainNotebook now tries to open its own KWUserInterfaceManager.  This causes problems because they are children of a MimxMainWindow that hasn't really been created.
* Create a separate notebook instance, vtkMeshingWorkflowNotebook, to function as the dispatcher.
* the MimxViewProperties was created as part of the main window before, instantiate this in the MeshingWorkflowGUI directly, instead.