Bug on model load due to change in VTK API between version 5 and 6

[robotsinthesun]

I have tried to test monkeyprint and got it to run, but when I tried to load a .stl, I got the following error: — Traceback (most recent call last): File “/home/sebste/Projekte/Software/Playground/monkeyprint/monkeyprintGui.py”, line 1721, in callbackLoad self.modelCollection.add(filename, filepath) File “/home/sebste/Projekte/Software/Playground/monkeyprint/monkeyprintModelHandling.py”, line 544, in add self[modelId] = modelContainer(filenameOrSettings, self.programSettings, self.console) File “/home/sebste/Projekte/Software/Playground/monkeyprint/monkeyprintModelHandling.py”, line 63, in init self.model = modelData(filename, self.settings, programSettings, self.console) File “/home/sebste/Projekte/Software/Playground/monkeyprint/monkeyprintModelHandling.py”, line 857, in init self.slicerThread = backgroundSlicer(self.settings, self.programSettings, self.queueSlicerIn, self.queueSlicerOut, self.console) File “/home/sebste/Projekte/Software/Playground/monkeyprint/monkeyprintModelHandling.py”, line 1953, in init self.sectionStripperModel.SetInput(self.cuttingFilterModel.GetOutput()) AttributeError: SetInput

[robotsinthesun]

Fix didn't work...

[kakaroto]

Hi @robotsinthesun ! We're looking into monkeyPrint, and are having some troubles with it (huge memory usage right before slicing, a lot of segfaults and python Fatal aborts (issue #1), which seem to be caused by a multi-threading/race condition during slicing, and the lack of a vtk6 port (issue #4)). I've started working on porting monkeyPrint to VTK6, and I've pushed the changes here : https://github.com/kakaroto/monkeyprint/commits/vtk6 This allows loading the stl and it becomes visible in the main window, however, there are still a couple of errors on the terminal :

ERROR: In /builddir/build/BUILD/VTK-6.1.0/Filters/Core/vtkClipPolyData.cxx, line 176
vtkClipPolyData (0x3151530): Cannot clip without clip function or input scalars

ERROR: In /builddir/build/BUILD/VTK-6.1.0/Common/DataModel/vtkCellLocator.cxx, line 1216
vtkCellLocator (0x31540d0): No cells to subdivide

ERROR: In /builddir/build/BUILD/VTK-6.1.0/Common/DataModel/vtkCellLocator.cxx, line 1216
vtkCellLocator (0x31540d0): No cells to subdivide

ERROR: In /builddir/build/BUILD/VTK-6.1.0/Filters/Core/vtkMassProperties.cxx, line 80
vtkMassProperties (0x32589d0): No data to measure...!

so the problem now is with the vtkClipPolyData in the VTK pipeline. I haven't been able to figure out what it's for, what it does, what it clips, and against what (I have no prior knowledge of VTK), but I have figured out that the implicit function in the ClipPolyData is not set, so it should be using the input data's scalars. According to the VTK source code (http://web.mit.edu/16.225/dv/VTK/Graphics/vtkClipPolyData.cxx - RequestData()), it will do a GetPointData() on the Input, then GetScalars() on that PointData, and in both VTK 5 and VTK 6, that GetScalars returns None. I have also checked that the ImplicitFunction is indeed set to NULL for both VTK 5 and VTK 6 (by enabling the GenerateClipScalars and getting the error "Cannot generate clip scalars if no clip function defined" instead), however, in both VTK 5 (I checked 5.10 source) and VTK 6 (6.3), the source code for PolyClipData hasn't changed, the logic is the same, however, the error happens only with VTK 6, so I have no idea why that is. And if I want to fix it, what am I supposed to do ? Should I call SetScalars on the input's PointData, and if yes, what data/scalars should I give it (I don't know yet what scalars even mean in this context). If you have any ideas on how to get that fixed, I'd appreciate it.

I am hoping that once we get it ported to VTK 6, the crashes (issue #1) will disappear, because it might be a bug in the VTK 5 python module, if not, at least, I should be able to investigate it now on my system and hopefully fix it quickly (I am currently using a Virtual Machine for testing/debugging with VTK 5, which is pain considering the VM needs to use most of my laptop's RAM otherwise python gets Killed by the kernel due to an out of memory error because of the huge memleak during slicing)

[robotsinthesun]

Hi Youness,

I've looked into migrating to VTK 6 myself and found it pretty confusing. The main aspects are described here: http://www.vtk.org/Wiki/VTK/VTK_6_Migration/Replacement_of_SetInput There seems to be a clear distinction between data objects and pipeline objects now which require to use the respective input functions SetInputData and SetInputConnection.

The vtkClipPolydata is the filter that clips all stl faces that have their normals oriented below the specified overhang angle. It get's a scalar clipThreshold to determine which faces can be clipped and which may not. I don't think there's a difference in setting the scalar between 5 and

6. It must be the input. The whole pipeline has to be set up a little different I guess.

Unfortunately, I don't have time to work on this until next week. Also, my suggestion would be to concentrate on the memory usage and the crashes. I don't think, that this is related to the VTK version. Could you send me the stl that you're using? I have encountered the crashes, but not the high memory usage. I could I've planned a recoding of the slicer thread. At the moment it slices the whole model in one go and outputs a stack of slice images to the model collection once it's done. At the moment I primarily use this image stack to show the preview in the GUI. For the print process itself, the slicing could be done one by one during the print, there's no need to do it before printing. This would prevent memory usage. For the preview in the GUI I'd to the full slicing but only in a reduced resolution to save memory. I had this on my mind for quite some time now and could do it next week I guess.

I've also thought about migrating to OpenGL for the slicing. VTK is nice, but it adds a lot of overhead to the whole project...

Regarding the changes you make: is there a way to get them back into my repo (I guess you'd have to do a pull request). Sorry for the question, I'm a git noob...

Hope this helps you a bit! How do you want to proceed?

Best, Paul

On 18.10.2016 00:31, Youness Alaoui wrote:

Hi @robotsinthesun https://github.com/robotsinthesun ! We're looking into monkeyPrint, and are having some troubles with it (huge memory usage right before slicing, a lot of segfaults and python Fatal aborts (issue #1 https://github.com/robotsinthesun/monkeyprint/issues/1), which seem to be caused by a multi-threading/race condition during slicing, and the lack of a vtk6 port (issue #4 https://github.com/robotsinthesun/monkeyprint/issues/4)). I've started working on porting monkeyPrint to VTK6, and I've pushed the changes here : https://github.com/kakaroto/monkeyprint/commits/vtk6 This allows loading the stl and it becomes visible in the main window, however, there are still a couple of errors on the terminal :

|ERROR: In /builddir/build/BUILD/VTK-6.1.0/Filters/Core/vtkClipPolyData.cxx, line 176 vtkClipPolyData (0x3151530): Cannot clip without clip function or input scalars ERROR: In /builddir/build/BUILD/VTK-6.1.0/Common/DataModel/vtkCellLocator.cxx, line 1216 vtkCellLocator (0x31540d0): No cells to subdivide ERROR: In /builddir/build/BUILD/VTK-6.1.0/Common/DataModel/vtkCellLocator.cxx, line 1216 vtkCellLocator (0x31540d0): No cells to subdivide ERROR: In /builddir/build/BUILD/VTK-6.1.0/Filters/Core/vtkMassProperties.cxx, line 80 vtkMassProperties (0x32589d0): No data to measure...! |

so the problem now is with the vtkClipPolyData in the VTK pipeline. I haven't been able to figure out what it's for, what it does, what it clips, and against what (I have no prior knowledge of VTK), but I have figured out that the implicit function in the ClipPolyData is not set, so it should be using the input data's scalars. According to the VTK source code (http://web.mit.edu/16.225/dv/VTK/Graphics/vtkClipPolyData.cxx - RequestData()), it will do a GetPointData() on the Input, then GetScalars() on that PointData, and in both VTK 5 and VTK 6, that GetScalars returns None. I have also checked that the ImplicitFunction is indeed set to NULL for both VTK 5 and VTK 6 (by enabling the GenerateClipScalars and getting the error "Cannot generate clip scalars if no clip function defined" instead), however, in both VTK 5 (I checked 5.10 source) and VTK 6 (6.3), the source code for PolyClipData hasn't changed, the logic is the same, however, the error happens only with VTK 6, so I have no idea why that is. And if I want to fix it, what am I supposed to do ? Should I call SetScalars on the input's PointData, and if yes, what data/scalars should I give it (I don't know yet what scalars even mean in this context). If you have any ideas on how to get that fixed, I'd appreciate it.

I am hoping that once we get it ported to VTK 6, the crashes (issue #1 https://github.com/robotsinthesun/monkeyprint/issues/1) will disappear, because it might be a bug in the VTK 5 python module, if not, at least, I should be able to investigate it now on my system and hopefully fix it quickly (I am currently using a Virtual Machine for testing/debugging with VTK 5, which is pain considering the VM needs to use most of my laptop's RAM otherwise python gets Killed by the kernel due to an out of memory error because of the huge memleak during slicing)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/robotsinthesun/monkeyprint/issues/4#issuecomment-254354046, or mute the thread https://github.com/notifications/unsubscribe-auth/AMuKpwknTeDLYoo4tepTneZ2uEpPo6Olks5q0_dYgaJpZM4JD3Wn.

[robotsinthesun]

Hi @kakaroto I've made some changes to the slicer code in my last commit to the fixSlicer branch. I think the problem was that I only gave the references to the VTK polydata of the model to the slicer thread. It now is a deep copy of the data so the slicer thread does not have to access the polydata from the main thread. Only problem now is that the gui sometimes freezes after the slicer has finished. I will investigate further...

[kakaroto]

Hi Paul,

Yes, the VTK migration is indeed pretty confusing, especially since VTK itself is confusing for me. I've figured out the SetInputConnection/SetInputData changes, as well as the required changes for AllocateScalars for example. But for some of the things to not work as expected, that's where the confusion is.

I've figured out the ClipPolyData issue! The problem was "where does the scalars get set" and that was my mistake, the GetNormalZComponent was throwing an error because of the GetArray('normals') not existing, I thought it was another vtk 5 vs 6 change, so i commented it out temporarily (https://github.com/kakaroto/monkeyprint/commit/c47271c616d8463df28628626fcb12c51fcb5714#diff-482902a20aec67bbce0aadd12d164d0cL1156) and that was long before the Clip issue occured, so i didn't realize they were related. Anyways, that was what i needed to understand, how the 'scalars' are getting set, and that's where they are. I think the GetArray wasn't working before due to a missing Update() on the stlReader before the GetOutput() was called. Anyways, now that the pipeline is setup correctly, the clipPolyData doesn't throw an error anymore. However, I get warnings from the VtkCellLocator, so that's where I'm stuck right now (the 'no cells to subdivide' and 'no data to measure' from my previous comment).

I'm currently concentrating on the vtk migration because I only have vtk 6 on my system and for me to fix the memory/crashes issues i need to be able to test on my system rather on a VM. I'm close though :)

I don't know about the OpenGL migration, it might be a good idea. If VTK is causing more issues than it's preventing, then it would be a good idea to move away from it. But I know almost nothing about openGL and nothing about VTK, so I'm not the right person to ask I guess.

If you want to merge my changes, you can wait for a pull request, and do it automatically using the github web page, but you can also do it manually, and without the need for a pull request. I didn't send a pull request though because the VTK migration is not done, and I tend to do that only when a feature or bug is complete. I only showed you the branch so you could see the changes I did. Anyways, to merge it manually, you can do this :

git remote add kakaroto https://github.com/kakaroto/monkeyprint.git
git fetch kakaroto
git merge kakaroto/vtk6

As for the deep copy, that's good, because I was thinking that if the problem is not a race condition in the VTK multithreaing, then it's with a race condition in the python threads that are both accessing the same data. I thought though that python was thread-safe, but i've now found out that you need to explicitely mutex your variable accesses between python threads. Unfortunately... your changes in fixSlicer are causing a lot of conflicts with my vtk6 branch! I'll rebase my work on your branch and fix the conflicts, then we'd probably need to merge things soon to avoid further conflicts. Thanks!

[kakaroto]

And it looks like the cell locator issue is caused by the stl itself! I realized I get the same error on vtk5! As I was using this stl file : https://www.thingiverse.com/download:17274 Before the overhangClipFilter gets its value set correctly in updateOverhang, the number of cells in the polydata is 14, once it gets set, the number of cells drop to 0, causing the 3 errors to appear in the terminal. I've used a different stl now and the errors all disappear, so displaying the model is now working and has been properly ported to vtk6! Now, the slicing however, is not working, and these are the errors I get :+1:

Model bounds: [23.72618865966797, 40.27381134033203, 1.0, 39.0, 5.0, 8.102679252624512].
Width and height: (297, 640).
Slice 0.
ERROR: In /builddir/build/BUILD/VTK-6.1.0/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx, line 1193
vtkStreamingDemandDrivenPipeline (0x7f548002f6d0): The update extent specified in the information for output port 0 on algorithm vtkTrivialProducer(0x7f548002f2c0) is 0 296 0 639 0 0, which is outside the whole extent 0 -1 0 -1 0 -1.

ERROR: In /builddir/build/BUILD/VTK-6.1.0/Common/ExecutionModel/vtkTrivialProducer.cxx, line 268
vtkTrivialProducer (0x7f548002f2c0): This data object does not contain the requested extent.

ERROR: In /builddir/build/BUILD/VTK-6.1.0/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx, line 1193
vtkStreamingDemandDrivenPipeline (0x7f5480034b30): The update extent specified in the information for output port 0 on algorithm vtkTrivialProducer(0x7f5480034720) is 0 296 0 639 0 0, which is outside the whole extent 0 -1 0 -1 0 -1.

ERROR: In /builddir/build/BUILD/VTK-6.1.0/Common/ExecutionModel/vtkTrivialProducer.cxx, line 268
vtkTrivialProducer (0x7f5480034720): This data object does not contain the requested extent.

ERROR: In /builddir/build/BUILD/VTK-6.1.0/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx, line 1193
vtkStreamingDemandDrivenPipeline (0x7f5480039a50): The update extent specified in the information for output port 0 on algorithm vtkTrivialProducer(0x7f5480039b50) is 0 296 0 639 0 0, which is outside the whole extent 0 -1 0 -1 0 -1.

ERROR: In /builddir/build/BUILD/VTK-6.1.0/Common/ExecutionModel/vtkTrivialProducer.cxx, line 268
vtkTrivialProducer (0x7f5480039b50): This data object does not contain the requested extent.

Slice 1.
Slice 2.
Slice 3.
Slice 4.
[etc...]

[robotsinthesun]

I think the "no cells to subdivide" warnings can be ignored. The probably result from my mechanism of creating the supports. I create a grid of vertical lines inside the model's bounding box. Then, I intersect these lines with the overhang mesh of the model. If the overhang region is smaller than the bounding box (which is the case almost everytime), no intersection can be found by the cell locator for some of the vertical lines. That's what creates the warning.

How are you getting along with the VTK migration? If there's anything I can do, please let me know!

[kakaroto]

Ah ok, that makes sense. The VTK migration is pretty much done, the only warnings I see is with those extends, but unfortunately, slicing simply doesn't work. I've found that one of the warnings above is caused by a bug in VTK 6.1, which is the version that I have. https://github.com/PointCloudLibrary/pcl/pull/1009 And this is apparently the fix for it in VTK: http://www.vtk.org/gitweb?p=VTK.git;a=commitdiff;h=1a0b4e9dde815f84e48ee9912d19be9687c97399

From what I can gather, it's caused by giving a polydata as input to the pipeline instead of setting some actual source and link it with SetInputConnection instead of SetInputData. But I tried changing the pipeline by passing the filename to the slicer thread instead of the model polydata, and using a new stlReader and passing the connection to the cuttingFilterModel, but it didn't change anything. I'm going to try to simplify the pipeline and see if I can get something trivial to work then expand on it until I have the bug reappear.

[kakaroto]

Ha! I got it to work! :D My mistake was thinking that I needed to replace the inputModel polydata and use SetInputConnection instead of SetInputData, but that was not it. It was in the stencil, I was using SetStencilData instead of SetStencilConnection, and that's where I made an error. I changed that to use SetStencilConnection and now slicing works! However, the 3D preview window doesn't display anything now when in slicing mode, is that because of your changes in the fixSlicer thread (which I merged) or is there still something missing from my vtk port ? Either way, I'm going to send you a pull request now with the VTK port I did.

[kakaroto]

I figured out why the preview was empty in the slicing tab, it was because the AppendPolyData was using AddInputData (since AddInputConnection doesn't exist in VTK6), and apparently that doesn't work. I've changed it to manually manage the input connection of the AppendPolyData and I set the input connections manually and now it works! you can see the changes here : https://github.com/kakaroto/monkeyprint/commit/be03838db05abe221c7f668a98f544fdd3d8677c

[kakaroto]

Thanks for merging PR #9. This issue can be closed now.