In preview version 4.11.0-2019-10-23, in orthographic rendering, shading changes when default orientation buttons are clicked after zooming in and out. See attached videos comparing current stable (4.10.2) and preview versions. It is reproducible on Windows 10 and CentOS 7.
Unexpected behavior in preview version:
[https://www.dropbox.com/s/x0vjmr8i3fmtlx0/preview.mp4?dl=0]
Stable version:
[https://www.dropbox.com/s/1r327yz1h0vn86z/stable.mp4?dl=0]
Thanks for the clear report 
I suspect this is something with the new opengl backend of vtk that we use in the latest slicer.
Often the best way forward is to try replicating the issue in native vtk, like in one of the examples.
Thanks for the quick response, @pieper. I know a little bit VTK but I haven’t done any coding for Slicer. For example, which functions are called in VTK when you set default orientations in Slicer? How does Slicer sets ortho projection in VTK? Any pointers?
There are multiple layers involved in slicer, but hopefully the effect could be captured in a simple easily reproduced script by changing the camera parameters in something like this script.
Also, now that I think about it, can you confirm whether this same effect happens with the CPU volume rendering, or only with the GPU (this would be another thing to capture in an example script).
It’s only with GPU Ray Casting but that’s the only thing my lab uses. I’ll try VTK scripting - I assume it’s VTK-8.2.0?
I can replicate this with MRhead.nrrd using cpu rendering. It is a lot more subtle than GPU raycasting, but it is there (Windows 10, r28545)
I cannot reproduce using this simple VTK script where I
- read the CTHead from sample data as .vtk object (I checked Slicer with this file and the behavior is still the same),
- rotate the camera with right mouse click.
- zoom in and out
- right click on the screen to change the camera angle
but the shading seems to be OK. I used PythonSlicer executable from preview.
But again, I am not sure this is the way default orientation buttons change the 3D view.
Good catch.
The lighting change is because default light in a renderer is a headlight, which is a light fixed to the camera’s position. When in parallel projection mode, the camera distance is changed when you click the standard view orientation buttons, based on current zoom factor (see ctkVTKRenderView::lookFromAxis).
This camera position change is unnecessary for perspective projection (we have separate functions for resetting field of view) and causes unexpected lighting update for parallel projection, so it should be removed. Pull request with a fix submited.
2 Likes
Quick question @lassoan, will this also fix the cropping effect in 3D rendering of segmentations? It happens in ortho projection when the same default orientation buttons are clicked. The portion of the 3D rendering closer to the camera is cropped if zoomed in. I believe VTK renderer has a clipping range and it seems related. Again, this was not the case in stable version. See below:
3D rendering of a segment via “Show 3D” button (it also happens with any model (mesh):
Zoom in and click on A (anterior) direction button from the top-left pin:
Zooming out to show the cropping:
When you rotate the rendering, the cropped area is still the nearest portion of the rendering, again probably due to the camera clipping range.
The fix has been available for almost a week now (in Slicer Preview Releases), feel free to try it.
“Center the 3D view” button does not change zoom factor or camera position in parallel projection mode, so you can still end up having objects clipped by the camera clipping plane. If you press r key on the keyboard then the camera is moved and zoom factor is changed to ensure that the everything is visible.
This difference between the center button and r key is not intuitive for users (r key is very hard to discover). We already have a bug report for this: https://issues.slicer.org/view.php?id=4381 - I’ve re-targeted it for Slicer-4.11.
Unless I am missing something, the preview version 2019-11-03 for Windows still has the first problem with the shading. Your fix seems to be not merged to the master -again I am a novice GitHub user and don’t know what goes into nightly builds.
You are right, the fix in CTK was not merged! I’ll take care of that tonight so that tomorrow’s preview release will contain it.
Thank you! I will check again tomorrow.
Just an update: I’ve been using the 2019-11-11 version for a while now. It works beautifully. But once in a while, when I am using dual 3D and loading and removing a bunch of CTs in the same session, the 3D rendering in the second 3D view ends up having the same shading problem. I cannot reliably reproduce the error. And it goes away when I remove the volume from the workspace and re-load.
It happened to me a couple of times when I do back-to-back “Close the Scene and load 2 new volumes, render them in two separate 3D views”. First I thought it only happens when
- Render the volume1 in both 3D views,
- Turn on the volume1’s visibility in the view2,
- Render the volume2 (which renders in view1 only automatically since that’s state of the volume rendering module),
- Turn off the visibility of the volume2 in view1 (which automatically turns it on both views),
- Turn off the visibility of the second volume in the view1 again - then you have a bogeyman in 3D view2.
I checked the cameras and everything but could not identify what it is and it doesn’t reproduce every time I do the same sequence. I fiddled with changing the inputs settings before and after turning on the visibility, still couldn’t figure out the exact sequence of events. If I figure it out, I will let you know. Maybe the fact that it only happens with 2 3D views and after close-the-scene can help you identify it.