Behavior of MTime after it gets reset due to continuous changes or running a long session

Support
1

I am using a vtkCutter with a vtkPlane as the Cut function to visualize a dataset.

I am running a loop where I continuously modify the cut plane’s origin/normal. Everything works fine till the Modified Time of the cut plane reaches close to the limit (VTK_UNSIGNED_INT_MAX)

Now, I reach a scenario where the MTime has reached close to the VTK_UNSIGNED_INT_MAX.
If I change the cut function (say, changing the origin/normal of the vtkPlane), the cutter output does not update. It seems like as the MTime reaches its maximum, it gets reset from zero.

I observed that (after the reset) the MTime of the cutter is ahead of the MTime of the cut plane (and hence, the cutter actor does not redraw ?). Basically, once I reach this stage of the maximum MTime, my pipeline gets broken and I can not use the same cutter and cut plane any more even after their MTime individually have been reset.

Can there be a scenario where the Modified Time of the Cut plane , Cutter and the Actor are not in the same cycle of the MTime - say two of them are close to the limit and the third one is reset to a small integer value > zero ?

Will be very helpful if I could get any pointers on this.

Thanks,
Santosh

2

VTK has been supporting 64-bit counter for MTime for years (see vtkType.h). Double-check what vtkMTimeType you have configured for your VTK build.

3

I should have mentioned that I am using VTK-6.3.0 on windows.
I suspect that the 64-bit counter for MTime is not available for this version of VTK
Is upgrading to a newer VTK the only option to avoid the MTime behavior ?

4

You can backport the MTime change into VTK6, but of course it is much better if you can upgrade from this ancient VTK version to a recent one because there have been many other significant fixes and improvements.

5

Sure Andras. I understand that VTK-6.3.0 is fairly old.
I have a doubt regarding the increase in MTime. Does the MTime increase by the number of cells I am displaying? Because, each time i call Render the MTime jumps by tens of thousands or even lakhs. I just want to know if there is something wrong in my pipeline. I have a cutter acting on an unstructured grid. My pipeline is like vtu -> vtkThreshold (one or more of these thresholds) -> vtkCutter -> Mapper -> Actor

Thanks,
Santosh

6

Modified time is generated by a global counter that is incremented each time vtkTimeStamp::Modified() is called. If you see jumps by tens of thousands then probably you have a quasi-infinite loop in your application (probably via event observations or GUI updates). Running your application using a profiler should pinpoint the hot loop.

7

Thanks … I will check if there are any such loops in my application.

8

I backported the vtkTimeStamp changes to VTK-6.3 to achieve the 64 bit counter for ModifiedTime and the problem of the MTime overflow is solved. Thanks Andras for the suggestion.

Regarding the jump in MTime, I can see that a simple pipeline like
vktUnstructuredGrid -> vtkCutter does result in a jump in MTime of the cutter by approx. 3 times the number of the cells in the unstructured grid on each render. I tried this in a simple script without any GUI events.

9

There may be a bug in vtkCutter that unnecessarily calls Modified() too many times. There is a good chance that this was fixed since VTK-6.3 was released.