Hi devs and users. I would be interesting in developing Dinamyc Modeler’s tools for:
adding parametric models for all available vtkSourceFilters that give a 3d mesh.
also adding a glyph tool that according to markup points and optionally the normals of a model uses the Glyph filter of vtk for creating copies of the input model with the corresponding position and orientation
This features would be helpful on surgicalGuides creation, considering making guideBases is already possible with the dynamic modeler.
Also I have a question:
Looking at the vtkbool code that is used on the CombineModels module… there is an AtoB matrix that is hardcoded to the identity… what if I define it according to the input transforms and make the processing cost less for transformed inputs… may be we could also do a Dynamic Modeler Boolean operations tool that is fast and parametric (transform-wise)
Please give comments about your interest on these features if you’d be user or implementation suggestion if you are a developer.
I’ve started working on the add models tool as weekend project.
Comments are welcomed
I’ll post my branch soon
I added another argument to the dynamicModelerWidgets that let’s you filter parametersWidgets depending on the value of another parameterWidget so they are not shown. This is needed since each sourceFilter has at least 3 parameters and right now I’m adding 15 sources to choose from on a combobox
I’m thinking this solution it is not good. It would be better just to add a “addGeometry” menu on the Dynamic modeler module where the user can select one of the different 15 different sources (each one would be a Tool and an action on the menu). This will result in at least 1 order of magnitude less qtWidgets hidden on the mainWindow.
You can add a “Shape” tool to Dynamic modeler. It could have a type selector combobox where you would choose between sphere, cylinder, cube, etc.
Code quality and complexity of vtkbool library is not well suited to be included in Slicer core. Ideally, vtkbool would need to be cleaned up and converted into a VTK remote module. But as a temporary solution, we could move over the files from Sandbox extension into the SurfaceToolbox.
Wouldn’t be easier to just use a menu button “Add geometry” and when it’s clicked a list of available Add-Geometry-Tools appear (e.g: “Add Arrow”, “Add Cube”, “Add Elypsoid”, etc)?
What do you think about my concern of too many parameter widgets per tool?.. I want to add 15 different sources and each has 3 parameters at least. That’s 45 parameter widgets per tool (if there is only one that is general). Maybe the GUI will become too slow…
I think it’s best to have 15 different new tools, each one with a parameter, I know it sound like too much at first but I think the other option is less optimal.
Adding a dropdown menu to the tool list would take considerable effort to implement and would not address all problems, such much larger amount of code to maintain (one class for each shape instead of 1) and users would not be able to easily switch between primitives.
If we just have 3-4 shape primitives then we may consider adding each as a separate tool, otherwise it would be simpler to manage all shapes with a single tool.
We need to review the shape list we want to support. Ellipsoid (sphere is special case), cylinder, prism (cube is special case), and cone would cover most use cases. If we add more complex shapes, such as arrow, needle, coordinate system axes, etc. then the number can go up, but I’m not sure if that these need to be dynamic models (e.g., we use SlicerIGT extension’s Create Models module for creating such models and it works fine).
If we have a single tool for all shapes, we still have only a handful of parameters (diameter x/y/z, number of sides, maybe a secondary diameter). It would be nice to implement a way to allow hiding parameter widgets depending on parameter values (e.g., do not show number of sides for a cube).
There should be no perceivable slowdown, even if you display a few hundred widgets.