Would be great if this improvement could be implemented in the near future ;-)

In recent nightly Slicer versions, conversion speed is so much improved that most likely background processing will not be necessary. The only processing step that is still slow is smoothing, which you can temporarily disable while you are editing the segmentation.

Without smoothing it's very difficult to see very small tunnel between outer and inner surface, see the example below:

WithoutSmoothing.PNG (805,152 bytes)

WithSmoothing.PNG (640,568 bytes)

Yes, so once you finished with the segmentation, you can enable smoothing to do some more assessment. I find that for the most part, during interactive segmentation, smoothing is not essential. We may add a toggle to make allow enabling/disabling smoothing with a single click.

@lassoan This works so well I'd suggest that the 3D toggle button be changed so that it flips between voxel and smooth mode. Or better, call it "Smooth", press to run-once, with a pull-down for mode changes. Default mode is update voxel 3D and then users won't ever have to change mode in most cases. The button could be greyed out when 3D smooth representation is current (after pressing it, before changing more voxels).

Could be an option, to have an shortcut to switch between smoothing and no smoothing, if this is really faster than switching between "Show 3D" on/off.

But in my case that won't help much because I use a pen display for segmentation, and all eight hot keys are already assigned.

IMO, the clean solution would be to decouple 3D view and editing or to buy better hardware? ;-)

Smoothing enable/disable is now much more easily accessible in Segment Editor (https://discourse.slicer.org/t/option-to-disable-smoothing-of-the-segment-surfaces-in-segment-editor/883/16?u=lassoan).

Temporarily disabling smoothing and the potential of using multi-volume rendering for displaying segments, makes priority of this issue very low. I'm tempted to closed this issue.

I agree that this feature is not really needed at the moment. Also it is quite hard to implement, so considering its priority, it's unlikely that we'll do it in the foreseeable future.

This issue is already in backlog, but if you can't imagine any use case where background conversion would be necessary, the we could close this issue. Not sure about the criteria about keeping an issue in backlog or closing as invalid...