|
|
| (11 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | 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.
| + | <big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [https://www.slicer.org/wiki/Slicer_Interactive_Module here]</font></big> |
| − | | |
| − | == 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.
| |
