vtkCubeSource / vtkBoxWidget coupling issue

Support
1

Hello vtk-Experts,

I’ve encountered yet another interesting problem. For a few years I have been developing an in-house tool using vtk and PyQt5. Currently I do not have a working minimal example, but I will build one if this query does not lead to anything.

My setup is the following: I am using a render viewport to display a box actor. It is a vtkCubeSource internally, coupled with a vtkBoxWidget, so the user can interact with the box the same way users can interact with a clip box in Paraview. I use a boxCallBack just as shown in the python examples at the vtk website. The callback function not only updates the vtkCubeSource but additionally sends the updated bounds of the box to another part of the UI where the numbers are put into QLineEdits. I want the user to be able to adjust the box visually as well as by the numbers in the QLineEdits. Next to the LineEdits, there is a button to update the visuals in the 3d-viewer, to hit by the user when he changed the bounds in the LineEdits (that circular arrow button).

My problem is: visually changing the BoxWidget works perfectly fine and it writes the correct bounds into the QLineEdits. Howevery, even when not manually changing the input, hitting the update button, leads to wrong display of the region, specifially the vtkCubeSource display (in blue) is off, while the BoxWidget remains correctly positioned. When again using one of the handles, the display of the vtkCubeSource jumps back into place.

I have already verified that the bounds send back and fourth are identical, so at no point the vtkCubeSource receives different data than the one shown. When hitting the button, the same bounds values are sent to the CubeSource via the .SetBounds() Method, while vtkBoxWidget is updated via its .PlaceWidget() method.

I am out of ideas why the CubeSource is off after updating and open for any suggestions. Currently the application is running on vtk 9.2.6 because I had issues migrating to a more recent release. My best guess right now is, that this is a bug and I need to get the latest version. However I’d like your opinion first to not waste time hunting down the problems I had migrating.

I have attached a gif of the process.
expl

2

Wild a** guess- there is a modified time issue…

3

Sorry, I might be missing the point. Where do you think does it go wrong?

I have just realized: when shifting only one handle for a certain distance, it appears the shifting distance is applied 2 times to the corresponding face of the vtkCubeSource. So visually pushing it 1 m away shows the cube 2 m larger. I will investigate …

4

Alright, I think I figured it out.
The boxWidget’s callback function applies the transform to the cube actor by

obj.GetProp3D().SetUserTransform(t)

(see: https://examples.vtk.org/site/Python/Widgets/BoxWidget/)
apparently, this transform is upheld as long as it is not overwritten or anything. Before hitting the update button, the actor shows the original bounds + transform as adjusted with the boxWidget. However, when updating the bounds with the new ones, the actor keeps its userTransform properties, effectively showing the original bounds + transform + transform (again!), which explains why increasing the length by 1 m, makes it bigger by two meters.

I was able to fix it, by overwriting the userTransform with an empty transformation object and updating the boxWidget and the cubeSource bounds later with the values from the QLineInputs.

# empty transform
t = vtkTransform()
cubeActor.SetUserTransform(t)
boxWidget.SetTransform(t)