I think that I am done for the week…
4 Likes
Thanks for sharing, this looks pretty amazing!
A fix has been implemented in the following pull request and will be integrated shortly. See https://github.com/Slicer/VTK/pull/45
@muratmaga @pieper For convenience, you may download the library libvtkOpenGL-9.2.so.9.2 from this folder and replace the one found in the install folder associated with Slicer-5.5.0-2023-10-16-linux-amd64.
This should allow to easily confirm everything work as excepted.
And here is the corresponding Slicer fix ready for review. See https://github.com/Slicer/Slicer/pull/7286
1 Like
Can confirm the preview build is now functional for volume rendering in linux. Thanks everyone.
1 Like
Also can confirm that it is now working. regex lol…
Is there a good reason why the first and last points in the volume rendering opacity transfer curves can only be dragged right left and not up down?
You can i think, but through the interface it is clunky. use the opacity button and either type in the value or use the up/down arrows.
Yes you can select the last point and then change its value using the spinner. I always want to change the last value to 1. Wondering if this on purpose. Paraview has a similar interface and I believe that the first and last values can be moved up and down with the mouse.
Lovely renderings.
A few things come to mind. The nice thing about this kind of technique is that there’s a cleaner break between medical data (the CT data) and graphical primitives (colored regions and volumetric detail) than in strict volume rendering.
In volume rendering, graphics and segmentation are all kind of smushed together. When we have good segmentation algorithms, we should use them instead of counting on the soft thresholding of scalars and gradients that volume rendering provide.
This technique allows us to push volumetric-like graphical properties into segmented scenes. And it looks great.
Some possible extensions:
-
instead of using CT, any scalar volume could be used. This could, for instance, but a synthetic volume computed from anything (like from multi-channel MR corrected for field inhomogeneities)
-
surface detail such as texture on bone might be able to be captured back into normal maps or bump maps for the surface segmentation.
-
It would be interesting to have a rendering model with a final 3D representation that was simpler than a full-blown volume rendering model that could be recolored but still look lovely. 3D point clouds and Gaussian splatting come to mind, with the colorizing of the points deferred until final 3D to 2D rendering.
A few questions:
— When using Lights. How does one reset?
— I’m having some trouble reproducing Colorize Volume runs. If I edit a segmentation or change the visible segments,the sliders “change”. After more than one run, the necessary threshold value becomes very small (~1%). Especially when there are more than one Colorized Volumes.
I think that this is an issue with repeatedly colorizing to the same volume. My work around is to colorize to a new volume and the sliders are reset.
1 Like
We can use any imaging modality, as the background opacity is automatically reduced (you can choose by how much). It would be nice if someone could post rendering of some segmented MRIs.
I agree, this could be a nice improvement on the state of the art surface rendering using fake textures (designers download some textures and normal/bump maps and apply it on the models to make them look more “realistic”).
Volume rendering is still better in that you can see through thick semi-transparent objects, but I admit that usually it is not necessary to see very deeply inside or through objects.
Somewhat related work is that we can now use the depth buffer to improve lighting in volume rendering - see Screen-space ambient occlusion for volume rendering - #26 by lassoan. This depth information could be captured in a bump map.
Interesting. Are point clouds or Gaussian splatting faster or simpler to do on current GPU hardware than raycasting?
Click Default for lighting, disable ambient shadows, and click None for image-based lighting. That said, there might be some things that we don’t reset exactly - that’s why Lights module is still in the sandbox. We’ll move features into Slicer core as we understand what features are useful enough and what is the best way to use them.
If you mean that you choose a different volume for output than your input volume then that is not a workaround but that is how the module is intended to be used. If you use a different input and output volume and you still see some drift then take a screen capture video (or take a screenshot and describe every click you make).
Your coronary rendering looks very nice!
1 Like
To everyone who is following this topic but may have missed the other topic about ambient shadows: check it out here.
It should be available in the Slicer Preview Release soon (hopefully within a couple of days).
1 Like
When I go into Lights and select View1.
There is an immediate change.
As you say, this is Default, …
Is there a way to get back to the state before I activated the Lights Module? Not sure if that is the intended behavior?
Alsi, I’m not sure if one needs to turn off the “Sand Box Light” or “Default” is not the ““Default””.
Modules in Sandbox extension are experimental, for making features available for early testing before the final feature is developed and integrated into Slicer core. When we implement lighting editing feature in Slicer core then we’ll always explicitly set the lights and provide saving/restoring of light configurations. However, we will not implement these in the Sandbox.
The changes in lights are not persistent, so if you want to reset to the VTK default then you can save the scene, restart Slicer, and load the scene. If you frequently want to go back to the default VTK lighting then you can check in VTK where the default light is placed and add lighting preset button corresponding to that. I guess it is just a single head light. You should be able to find it in the VTK source code or ask on the VTK forum.