Operating system: Windows 10
Slicer version: 4.10.1 r27931
Expected behavior: starting with images that are stacks of binary images,with model maker I generate a 3D view, In the rotation of the 3D views I expect to see the whole volume for all points of view
Actual behavior: when one dimension of these stacks, is clearly longer than the two others, typically 28 x 10 x 5, In my case the x axis of the 2D images is the longest, when rotation the volume, when I set the long length perpendicular to the screen the extremities are missing, as if the working volume available would not be a cube calculated from the longest dimension. Is there a way to decide the working volume sizes? or to set the view point outside the whole volume range in all positions?
It sounds like you need to set the volume spacing.
https://slicer.readthedocs.io/en/latest/user_guide/modules/volumes.html#panels-and-their-use
If thatās not it maybe post some screenshots to explain what you are seeing.
It sounds like this could be due to the cameraās clipping range. Perhaps it is automatically set for the initial view and not updated during the rotation. Does that seem consistent with what you are seeing? What happens if you zoom in or out using the mouse scroll wheel when part of the structure is missing? Do you see more or less of the ends? If so, I strongly suspect it is due to the camera clipping planes.
Thank you for your answers. Here are images showing the problem : the entire volume
when rotating, the whole front end missing
and a de-zoom of the same, showing no improvement
Steve, when you say āset the volume spacingā, do you mean in the āvolumesā module? Isnāt it rather for setting image properties, and not really the working volume around the 3D image stack?
Mike, is this camera clipping range accessible through mouse controlled operations or do I need to programs such as
viewNode = slicer.mrmlScene.GetSingletonNode(ā1ā, āvtkMRMLViewNodeā)
cameraNode = slicer.modules.cameras.logic().GetViewActiveCameraNode(viewNode)
position = [0,0,0]
focalPoint = [20,20,20]
viewUpDirection = [0,1,0]
cameraNode.SetPosition(position)
cameraNode.SetFocalPoint(focalPoint)
cameraNode.SetViewUp(viewUpDirection)
and up to now I never went that deep in the use of 3D slicer 
You shouldnāt need to use the python commands to set the view if all you want to do is rotate. The clip planes should be automatically reset for you.
Looks like you are using an old version of Slicer. Can you try the latest preview version? If you are still having trouble maybe you can share the data and see if someone else can replicate.
Hello again, so, yes I installed 5.0.1 r30814 / fff8c39, and I am happy because now I can use the sandbox extension that I could not find previously, with the lightning control, that will solve a problem I had.
About my question, the change in version does not seem to solve the problem. Maybe it behaves a bit differently but still strangely to me. I built a test image stack, the corresponding scene, and two animated rotating gifs, one worked correctly and not the other. The difference was the starting point, when starting from the "I " position (or the āSā) it vanishes in the rotation, when moving slightly from this position it sometimes works correctly sometimes not. You should find these files in
https://filesender.renater.fr/?s=download&token=a3b66242-a6d8-4fd3-856f-444620cfef68
Iāll be happy to know what Iām doing wrong.
Thanks for sharing the data. I load it in my Slicer and I donāt see the issue you reported. Maybe someone else can replicate?
Mmmm, strangeā¦did you try the Screen Capture yaw rotation starting from the āIā position?
No, I just looked on the screen while rotating with the mouse or using the spin button in the view controller. If you are using Screen Capture and get different results thatās an important clue. Maybe we need to add the call to reset clipping planes to the Screen Capture render loop.
ScreenCapture module uses the CTK render viewās yaw and pitch methods, which indeed do not reset the camera clipping range after rotation, so clipping can occur. Iāll add the reset to CTK. Until then you can edit your ScreenCapture.py file in your Slicer installation and add the following line above this line:
slicer.modules.cameras.logic().GetViewActiveCameraNode(viewNode).ResetClippingRange()Itās possible the lack of reset of the clipping planes is deliberate for the Screen Capture module. I recall needing to manually manage the clipping planes in the past when doing endoscopy-style animations because the auto-reset close plane was not close enough to the camera (close objects in the wide-angle field of view were clipped) and the far plane was needlessly distant (nothing being rendered was very far away because the view was inside the lumen of a structure). When learning about the clipping planes I recall that the ratio of the distance between the camera and the close clipping plane and the camera and the far clipping plane is important because it sets the resolution of the z-buffer bins. Because of this, you get different rendering problems if you move the close plane closer to the camera without also moving the far plane proportionally closer as well.
Having the clipping planes reset automatically is probably best for most use cases, so thatās probably the best default behavior. If there is a way to turn that off, that would be helpful for cases where clipping planes need to be managed more directly.
Yes, resetting clipping planes after manipulating camera parameters is not always desirable - probably that is why it is not done at very low level in vtkCamera. However, when the camera is manipulated using the GUI then it is probably the best option.
Iāve submitted a pull request to CTK to reset the camera clipping range in view rotation methods: