When I drag and drop volume to the 3D render, it automatically renders with the volume property MR. I would like it to use one of my custom presets that are registered via the .slicerrc.py (as per this instructions Volume rendering — 3D Slicer documentation)
Drag-and-drop to views are handled by the subject hierarchy owner plugin associated with the node.
One option is to create a custom subject hierarchy plugin that will recognize your special volume and “claim” it for itself by returning high confidence value for it in canOwnSubjectHierarchyItem method. Then implement in the plugin’s showItemInView any behavior that you need.
I have about 60 mouse skulls that are scanned and reconstructed the same way. I designed a custom volume property that renders them nicely. I have bunch of LMs to review. I load each volume and the markups file and then I am trying to cut down the number of click I get from loading the volume to rendering it in 3D.
I registered mine as SM_mouse, and is available as a preset now. But when I drag and drop my mouse volume into 3D viewer, it still renders with MR-Default, and I still have to choose my preset from the available preset. The goal is minimizing the interactions.
I ended up going with this route and it works quite well for my challenge.
However, this is slightly ‘hacky’ as in, if I distribute a presets.xml that contains various overwritten presets optimized for data that comes out of our scanner (so that my collaborators have the same settings), it is likely to confuse people (since I simply overwrote the MR-Default, and created a copy of it called MR-Default2 in case I do need it for MR datasets).
It would be great if the presets can be more easily added, and that defaults used for drag and dropping can be customizable…
There is an issue for this already. If it gets enough upvotes then we’ll get to it:
We could allow users to choose 3 custom default presets in the application settings. You can add a feature request in the issue tracker and see how much upvotes it gets.
In general, extensions should not modify user preferences (without explicitly getting approval from the user). So, probably the most appropriate level where an extension can inject its custom behavior into the application is to add a subject hierarchy plugin that recognizes certain volume types where the default VR preset is not optimal (e.g., I can imagine that you can create better preset for dry bone), claims those volumes (gives higher confidence value than all other plugins), and uses your custom volume rendering preset when display in 3D view is requested.
If the problem is that in general you don’t find the default VR presets optimal then we can change those presets or add new presets that will be used as default.