Add SlicerModelsVoxelization extension

[DomenicoRiggio]

New extension

Tier 1

Any extension that is listed in the Extensions Catalog must fulfill these requirements.

• Extension has a reasonable name (not too general, not too narrow, suggests what the extension is for). The extension name should not start with Slicer (unless it explicitly provides a bridge between Slicer and a tool or library), because it would make it more difficult to find extensions if the name of many started with the same word.
• Repository name is Slicer+ExtensionName (except if the repository that hosts the extension can be also used without Slicer)
• Repository is associated with 3d-slicer-extension GitHub topic so that it is listed here. To edit topics, click the settings icon in the right side of "About" section header and enter 3d-slicer-extension in "Topics" and click "Save changes". To learn more about topics, read https://help.github.com/en/articles/about-topics
• Extension description summarizes in 1-2 sentences what the extension is usable (should be understandable for non-experts)
• Any known related patents must be mentioned in the extension description.
• LICENSE.txt is present in the repository root and the name of the license is mentioned in extension homepage. We suggest you use a permissive license that includes patent and contribution clauses. This will help protect developers and ensure the code remains freely available. MIT (https://choosealicense.com/licenses/mit/) or Apache (https://choosealicense.com/licenses/apache-2.0/) license is recommended. Read here to learn more about licenses. If source code license is more restrictive for users than MIT, BSD, Apache, or 3D Slicer license then describe the reason for the license choice and include the name of the used license in the extension description.
• Extension URL and revision (scmurl, scmrevision) is correct, consider using a branch name (main, release, ...) instead of a specific git hash to avoid re-submitting pull request whenever the extension is updated
• Extension icon URL is correct (do not use the icon's webpage but the raw data download URL that you get from the download button - it should look something like this: https://raw.githubusercontent.com/user/repo/main/SomeIcon.png)
• Screenshot URLs (screenshoturls) are correct, contains at least one
• Content of submitted json file is consistent with the top-level CMakeLists.txt file in the repository (dependencies, etc. are the same)
• Homepage URL points to valid webpage containing the following:
  • Extension name
  • Short description: 1-2 sentences, which summarizes what the extension is usable for
  • At least one nice, informative image, that illustrates what the extension can do. It may be a screenshot.
  • Description of contained modules: at one sentence for each module
  • Publication: link to publication and/or to PubMed reference (if available)
• Hide unused github features (such as Wiki, Projects, and Discussions, Releases, Packages) in the repository to reduce noise/irrelevant information:
  • Click Settings and in repository settings uncheck Wiki, Projects, and Discussions (if they are currently not used).
  • Click the settings icon next to About in the top-right corner of the repository main page and uncheck Releases and Packages (if they are currently not used)
• The extension is safe:
  • Does not include or download binaries from unreliable sources
  • Does not send any information anywhere without user consent (explicit opt-in is required)

Tier 3

Community-supported extensions.

• Documentation, tutorial, and test data are provided for most modules. A tutorial provides step-by-step description of at least the most typical use case, include a few screenshots. Any sample data sets that is used in tutorials must be registered with the Sample Data module to provide easy access to the user.
• Follows programming and user interface conventions of 3D Slicer (e.g., GUI and logic are separated, usage of popups is minimized, no unnecessary custom GUI styling, etc.)
• The extension can be successfully built and packaged on all supported platforms (Windows, macOS, Linux)
• Maintainers respond to issues and pull request submitted to the extension's repository.
• Maintainers respond to questions directly addressed to him/her via @mention on the Slicer Forum.
• Permissive license is used for the main functions of the extension (recommended Apache or MIT). The extension can provide additional functionality in optional components that are distributed with non-permissive license, but the user has to explicitly approve those before using them (e.g., a pop-up can be displayed that explains the licensing terms and the user has to acknowledge them to proceed).
• All requirements of tiers < 3.

Tier 5

Critically important extensions, supported by Slicer core developers. New Slicer Stable Release is released only if all Tier 5 extension packages are successfully created on all supported platforms.

• Slicer core developers accept the responsibility of fixing any issues caused by Slicer core changes; at least one Slicer core developer (anyone who has commit right to Slicer core) must be granted commit right to the extension's repository.
• Automated tests for all critical features.
• Maintainers respond to questions related to the extension on the Slicer Forum.
• All requirements of tiers < 5.

[pieper]

This seems cool, but how is it different from what's already available in the Segmentation infrastructure? @lassoan

[DomenicoRiggio]

Hi @pieper, thank you very much for your comment,

We understand the concern. The current name/description may indeed be a bit misleading, and we would be happy to improve them to make the purpose of the extension clearer.

The extension is not meant to replicate Segment Editor functionalities. Its goal is to generate a voxel-based volumetric mesh made of regular hexahedral elements, with a user-defined pitch. The output is therefore not a labelmap and not a surface model, but a volumetric mesh with nodes and elements that can be used in FEM workflows, for example with SOFA-Slicer, or exported to other simulation tools.

The main difference from the Segment Editor / labelmap infrastructure is that the mesh resolution is controlled by the selected pitch, independently of the original image or segmentation resolution. The extension also lets users define a threshold for the minimum fraction of volume that a voxel must contain to be included in the final mesh, giving control over the boundary approximation and the trade-off between geometric fidelity, mesh size, and robustness.

Compared to Segment Mesher, that also generates volumetric meshes, the extension provides a different type of volumetric discretization: regular voxel/hexahedral elements instead of tetrahedral elements.

The extension also includes standard Boolean operations and the possibility to export the output meshes in different file formats.

We see this as a complementary workflow. Tetrahedral meshes are very useful, but tetrahedralization can require additional surface cleaning and preprocessing, especially for complex anatomical geometries. A regular voxel/hexahedral mesh can be useful when a more straightforward and robust volumetric discretization is desired, for example in preliminary, automated, or educational FEM workflows.

We presented a preliminary version of this work at the 3D Slicer Project Week in January 2026 and received encouraging feedback from participants interested in this workflow. We would be happy to discuss this further, clarify any remaining questions, and improve the extension, its name, or its documentation based on your suggestions.

[pieper]

Okay, I see, thanks for the clarification. There are some failing checks to look into.

[DomenicoRiggio]

Thank you @pieper, We have looked into the failing checks and working now on fixing the issues.

[lassoan]

It was not clear for me from the documentation what this extension can be used for. You could simply write that it provides a hexahedral mesher and give some information on the meshing strategy and intended use.

I would also recommend to consider using more of the already Slicer infrastructure and VTK, because it may dramatically reduce the amount of code that you need to maintain.

If the output is simply a uniform hexahedral mesh then vtkThreshold filter (followed by an optional append filter to merge points) could be used instead of bringing in trimesh.

Boolean operations are available for both models and segmentations (Combine Models module in Sandbox extension; and Logical operations effect in Segment Editor), and quantitative analysis is offered in Segment Statistics module. Resampling segmentations is available in Segment Editor (specify geometry) or in Crop Volume module. Saving in various formats are already available in File/Save and Export node. Additional import/export formats can be easily added by implementing file reader/writer plugins.

[kimiaghodoosi]

It was not clear for me from the documentation what this extension can be used for. You could simply write that it provides a hexahedral mesher and give some information on the meshing strategy and intended use.

I would also recommend to consider using more of the already Slicer infrastructure and VTK, because it may dramatically reduce the amount of code that you need to maintain.

If the output is simply a uniform hexahedral mesh then vtkThreshold filter (followed by an optional append filter to merge points) could be used instead of bringing in trimesh.

Boolean operations are available for both models and segmentations (Combine Models module in Sandbox extension; and Logical operations effect in Segment Editor), and quantitative analysis is offered in Segment Statistics module. Resampling segmentations is available in Segment Editor (specify geometry) or in Crop Volume module. Saving in various formats are already available in File/Save and Export node. Additional import/export formats can be easily added by implementing file reader/writer plugins.

Thanks for your comment. I am Kimia and I am one of the contributors of the project. Regarding your comments:

1. Documentation: We will add more detailed explanations to the README as soon as possible, clearly describing the extension as a hexahedral mesher intended for FEM simulation workflows.
2. Slicer infrastructure and VTK: We already use Slicer and VTK infrastructure wherever appropriate, specifically slicer.mrmlScene.AddNewNodeByClass(), CreateDefaultDisplayNodes(), vtkMassProperties, vtkSelectEnclosedPoints, and vtkTriangleFilter. The remaining custom code exists only where Slicer has no native support for our specific use case.
3. Replacing trimesh with vtkThreshold: We attempted the suggested approach: surface mesh → vtkPolyDataToImageStencil → vtkImageData → vtkThreshold → hex mesh. However, vtkPolyDataToImageStencil consistently produced empty results for arbitrary surface meshes in VTK 9.x, even when the mesh was correctly positioned within the image bounds. We tested with both world-space (RAS) coordinates and unit IJK coordinates but both failed. trimesh's mesh.voxelized(pitch).fill() is the only approach that worked reliably. We are open to suggestions on how to make vtkPolyDataToImageStencil work correctly in this context.
4. Boolean operations: Combine Models and Logical operators in Segment Editor both operate on surface meshes or segmentations at the original image resolution. Our boolean operations work on the voxelized hexahedral mesh at a user-defined pitch; operations are performed on integer voxel grid indices. The result must remain a hexahedral mesh to preserve the voxel structure for FEM export. Additionally Combine Models uses vtkbool which requires clean watertight surfaces. Voxelized hex meshes are non-manifold (adjacent cubes share faces) and cannot be processed by vtkbool.
5. Resampling in Segment Editor: Segment Editor and Crop Volume resample segmentations to a different voxel spacing while keeping the output as a segmentation or labelmap. Our extension does something fundamentally different. it converts a surface mesh or segmentation into a solid hexahedral mesh where each element is a cube of a user-defined edge size. This is a volumetric mesh suitable for FEM simulation, not a resampled segmentation. The edge size parameter controls the element size of the hex mesh, which directly affects FEM simulation accuracy and computational cost.
6. Export formats: We agree that VTK, STL, and OBJ are available through Slicer's built-in File/Save. We attempted to use slicer.util.saveNode() but it requires a storage node attached to the model node, which our programmatically created nodes do not have by default. For MSH (Gmsh 2.2), PLY, and OFF, none are available natively in Slicer. MSH is the primary format needed for our FEM workflow and is provided through a custom writer in our extension.
7. Quantitative metrics: Segment Statistics measures properties of segmentations at MRI resolution. Our metrics serve a completely different purpose, they measure voxelization error, specifically the volume difference (ΔV) between the original surface mesh and the resulting hexahedral mesh at the chosen edge size. No existing Slicer module provides this information.

[lassoan]

Replacing trimesh with vtkThreshold: We attempted the suggested approach: surface mesh → vtkPolyDataToImageStencil → vtkImageData → vtkThreshold → hex mesh. However, vtkPolyDataToImageStencil consistently produced empty results for arbitrary surface meshes in VTK 9.x, even when the mesh was correctly positioned within the image bounds. We tested with both world-space (RAS) coordinates and unit IJK coordinates but both failed. trimesh's mesh.voxelized(pitch).fill() is the only approach that worked reliably. We are open to suggestions on how to make vtkPolyDataToImageStencil work correctly in this context.

vtkPolyDataToImageStencil is used in Slicer core extensively and have not experienced any issues. It did not support image directions when we started to use it and it may still not support it, so we usually convert the model points to IJK coordinate system. Have a look at https://github.com/Slicer/Slicer/blob/28ef15df2165a150be97f52e426f22a7dfdbd20d/Libs/vtkSegmentationCore/vtkClosedSurfaceToBinaryLabelmapConversionRule.cxx for a complete example.

Boolean operations: Combine Models and Logical operators in Segment Editor both operate on surface meshes or segmentations at the original image resolution. Our boolean operations work on the voxelized hexahedral mesh at a user-defined pitch; operations are performed on integer voxel grid indices. The result must remain a hexahedral mesh to preserve the voxel structure for FEM export. Additionally Combine Models uses vtkbool which requires clean watertight surfaces. Voxelized hex meshes are non-manifold (adjacent cubes share faces) and cannot be processed by vtkbool.

Boolean operations are trivial on labelmap images (which are equivalent to hexa mesh on a uniform grid), so there is no need for Combine Models module, but simply resample the segmentations to the same grid and use numpy or VTK filters to combine the labelmap volumes.

Resampling in Segment Editor: Segment Editor and Crop Volume resample segmentations to a different voxel spacing while keeping the output as a segmentation or labelmap. Our extension does something fundamentally different. it converts a surface mesh or segmentation into a solid hexahedral mesh where each element is a cube of a user-defined edge size. This is a volumetric mesh suitable for FEM simulation, not a resampled segmentation. The edge size parameter controls the element size of the hex mesh, which directly affects FEM simulation accuracy and computational cost.

Segmentations module can convert surface mesh to labelmap at the desired resolution (you can adjust it in the segment representation conversion parameters). The labelmap is equivalent to a uniform hexahedral mesh, as the conversion is trivial (unless I miss something).

Export formats: We agree that VTK, STL, and OBJ are available through Slicer's built-in File/Save. We attempted to use slicer.util.saveNode() but it requires a storage node attached to the model node, which our programmatically created nodes do not have by default. For MSH (Gmsh 2.2), PLY, and OFF, none are available natively in Slicer. MSH is the primary format needed for our FEM workflow and is provided through a custom writer in our extension.

You can call AddDefaultStorageNode() to add a default storage node.

PLY is supported already. OFF is just for surface meshes and not very widely used. Probably it is better not to use it. MSH export using meshio is fine, but you don't need to add any custom GUI, but instead you can add a custom reader/writer and then the new file format will show up in the standard Save data dialog. See complete example here: https://github.com/Slicer/Slicer/blob/28ef15df2165a150be97f52e426f22a7dfdbd20d/Applications/SlicerApp/Testing/Python/SlicerScriptedFileReaderWriterTest.py#L118-L166

Quantitative metrics: Segment Statistics measures properties of segmentations at MRI resolution. Our metrics serve a completely different purpose, they measure voxelization error, specifically the volume difference (ΔV) between the original surface mesh and the resulting hexahedral mesh at the chosen edge size. No existing Slicer module provides this information.

Segment statistics gives you both the volume computed from the surface mesh and labelmap representation (i.e., the hexa mesh).

---

It is not required to use existing Slicer features, I just wanted to let you know that these features exist so that you can reduce the amount of code you need to maintain and support, if you want to.