[vtkusers] Viewport clipping

[Doug Hoppes]

Okay… I’ll see how hard it is to move our code back to OpenGL with the latest version and see if the problem persists.

Here’s the image with a different background.  As you can see, the vtkimageactor looks like it’s the correct size.

[cid:image002.png at 01D1D1F8.6BC12650]

If I use the mouse to drag the image over to the right (using the interactorstyle Pan()), I see:

[cid:image004.png at 01D1D1F8.6BC12650]

Doug



From: David Gobbi [mailto:david.gobbi at gmail.com]
Sent: Wednesday, June 29, 2016 11:15 AM
To: Doug Hoppes
Cc: vtkusers at vtk.org
Subject: Re: [vtkusers] Viewport clipping

For troubleshooting problems like this, use test images that don't have a black background. That way we can see where the boundaries of the images are.

It looks like the images are simply being rendered in the wrong position.  So the question is whether this is due to the fact that multiple viewports are being used (i.e. due to a bug in the display coords or view coords), or if this is due to a shift in the world coords.  Either way, this is strange because the OpenGL2 vtkImageSliceMapper simply uses a vtkPolyDataMapper under the hood.

There were many changes between VTK 6.2 and VTK 7.0... any chance that you can try this with the OpenGL backend in VTK 7.0 (instead of OpenGL2)?

Also, here is a very important question: do you create a separate vtkImageActor for each of your viewports?  Actors should not, in general, be shared between viewports.

 - David

On Wed, Jun 29, 2016 at 8:39 AM, Doug Hoppes <dhoppes at mbfbioscience.com<mailto:dhoppes at mbfbioscience.com>> wrote:

Notice the clipping. The upper two viewports show nothing, the bottom viewport is correct and the rightmost viewport is clipped in the center of the viewport. If we resize the overall vtk window, the viewport is still clipped in the center.  It seems that there is no display to the right-side of the viewport.  In the main right viewport, we can actually move the objects around without a problem but the results are still clipped.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160629/83359c4e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.emz
Type: application/octet-stream
Size: 28761 bytes
Desc: image001.emz
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160629/83359c4e/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 26181 bytes
Desc: image002.png
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160629/83359c4e/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.emz
Type: application/octet-stream
Size: 27453 bytes
Desc: image003.emz
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160629/83359c4e/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 25172 bytes
Desc: image004.png
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160629/83359c4e/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oledata.mso
Type: application/octet-stream
Size: 34553 bytes
Desc: oledata.mso
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160629/83359c4e/attachment-0005.obj>