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

Closed
robotsinthesun opened this Issue Jul 3, 2016 · 11 comments

Comments

2 participants
@robotsinthesun
Owner

robotsinthesun commented Jul 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@robotsinthesun

robotsinthesun Jul 3, 2016

Owner

Fix didn't work...

Owner

robotsinthesun commented Jul 3, 2016

Fix didn't work...

@robotsinthesun robotsinthesun reopened this Jul 3, 2016

@kakaroto

This comment has been minimized.

Show comment
Hide comment
@kakaroto

kakaroto Oct 17, 2016

Contributor

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)

Contributor

kakaroto commented Oct 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@robotsinthesun

robotsinthesun Oct 18, 2016

Owner

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
#1), which seem
to be caused by a multi-threading/race condition during slicing, and
the lack of a vtk6 port (issue #4
#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
#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
#4 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMuKpwknTeDLYoo4tepTneZ2uEpPo6Olks5q0_dYgaJpZM4JD3Wn.

Owner

robotsinthesun commented Oct 18, 2016

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
#1), which seem
to be caused by a multi-threading/race condition during slicing, and
the lack of a vtk6 port (issue #4
#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
#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
#4 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMuKpwknTeDLYoo4tepTneZ2uEpPo6Olks5q0_dYgaJpZM4JD3Wn.

@robotsinthesun

This comment has been minimized.

Show comment
Hide comment
@robotsinthesun

robotsinthesun Oct 19, 2016

Owner

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...

Owner

robotsinthesun commented Oct 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kakaroto

kakaroto Oct 19, 2016

Contributor

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 (kakaroto@c47271c#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!

Contributor

kakaroto commented Oct 19, 2016

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 (kakaroto@c47271c#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

This comment has been minimized.

Show comment
Hide comment
@kakaroto

kakaroto Oct 19, 2016

Contributor

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 👍

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...]
Contributor

kakaroto commented Oct 19, 2016

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 👍

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

This comment has been minimized.

Show comment
Hide comment
@robotsinthesun

robotsinthesun Oct 25, 2016

Owner

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!

Owner

robotsinthesun commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kakaroto

kakaroto Oct 25, 2016

Contributor

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.
PointCloudLibrary/pcl#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.

Contributor

kakaroto commented Oct 25, 2016

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.
PointCloudLibrary/pcl#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

This comment has been minimized.

Show comment
Hide comment
@kakaroto

kakaroto Oct 25, 2016

Contributor

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.

Contributor

kakaroto commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kakaroto

kakaroto Oct 25, 2016

Contributor

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 : kakaroto@be03838

Contributor

kakaroto commented Oct 25, 2016

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 : kakaroto@be03838

@kakaroto kakaroto referenced this issue Oct 25, 2016

Merged

Vtk6 support #9

@kakaroto

This comment has been minimized.

Show comment
Hide comment
@kakaroto

kakaroto Oct 26, 2016

Contributor

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

Contributor

kakaroto commented Oct 26, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment