Shading in the multi-volume rendering worked for a while for me, but in this dataset I am getting this error:
Loaded volume from file: C:/Users/amaga/Desktop/Cuke_9.9um_2k__rec_Cor0556 Segment_1_1.nrrd. Dimensions: 326x805x343. Number of components: 1. Pixel type: unsigned char.
vtkMRMLScene::Clear
"Volume" Reader has successfully read the file "C:/Users/amaga/Desktop/Cuke_9.9um_2k__rec_Cor0556 Segment_1_1.nrrd" "[0.19s]"
Loaded volume from file: C:/Users/amaga/Desktop/Cuke_9.9um_2k__rec_Cor0556 Segment_2.nrrd. Dimensions: 648x2233x780. Number of components: 1. Pixel type: unsigned char.
vtkMRMLScene::Clear
"Volume" Reader has successfully read the file "C:/Users/amaga/Desktop/Cuke_9.9um_2k__rec_Cor0556 Segment_2.nrrd" "[1.29s]"
The VTKEvent( 17000 ) triggered by vtkObject( vtkMRMLScalarVolumeNode ) doesn't return data of type vtkObject.
The slot ( "1onDisplayNodeModified(vtkObject*, vtkObject*)" ) owned by QObject( "" ) may be incorrect.
void __cdecl qSlicerSubjectHierarchyPluginLogic::onDisplayNodeModified(class vtkObject *,class vtkObject *) : Invalid object type calling display node modified event
The VTKEvent( 17000 ) triggered by vtkObject( vtkMRMLScalarVolumeNode ) doesn't return data of type vtkObject.
The slot ( "1onDisplayNodeModified(vtkObject*, vtkObject*)" ) owned by QObject( "" ) may be incorrect.
void __cdecl qSlicerSubjectHierarchyPluginLogic::onDisplayNodeModified(class vtkObject *,class vtkObject *) : Invalid object type calling display node modified event
What Slicer version did the correct rendering and which one failed? Does it work well if you downsample the volume? How the image changes if you move the shift slider? Do Advanced/Techniques/Quality settings make a difference?
This error is with the current stable. Last time I played with multi-volume rendering was in august, but I can’t remember the specific version it worked (it wasn’t with this dataset either).
As far as I can tell none of those settings make a difference.
Thank you for the sample images, I was able to reproduce the issue. The problem is that automatic sampling step computation does not work in the multivolume renderer, so the image spacing has to be approximately 1 to get good-quality rendering. The easiest is to edit spacing information in Volumes module (change the decimal point location). It would be great if you could enter a bug report for this so that we can investigate after VTK9 migration is completed.
Thank you. I am trying. But why is changing the location of decimal place is so hard in volumes? The field is trying to be smart at guessing what I am trying to do and failing miserably. For example, try shifting the decimal place one to the left in the origin tab of the MRHead. My behavior is to delete the decimal point and I can’t edit because the moment I delete that, Slicer adds a new decimal point at the end followed by 000.
I really find it frustrating that those field to do things automatically before I finish entering values.
I agree, it’s very annoying. The ctkDoubleSpinBox widget tries to be smart, but enforcing valid input during typing (after each keypress) is just so hard, probably in many cases it is not even feasible. See also this discussion. We should probably only validate values on Enter/leave.
Today I accidentally turned on the VTK MultiVolume Rendering on 5.2.2 and pleasantly surprised to see that shading is now supported even with the small voxel sizes.
Performance is slow with Normal quality, but quite reasonable with Adaptive setting. Also there seems a centering bug, but otherwise it actually looks quite nice.
I really like the new multi-volume rendering. it allows striking visualizations. It is so nice to see all these tools coming together (done in about 3 minutes using, total segmentator, SegmentEditor with split volumes, and volume rendering).
Now let’s have the cropping working in the MultiVolume Rendering and it will be great.