vtk modules with VTKCell input ports

[remram44]

Follows up on comments on c880fd4, see also #1030

Some vtk modules have VTKCell input ports.

• This means that vtk can't be loaded without the spreadsheet
• These modules should probably be SpreadsheetCell subclasses themselves
• No module currently outputs VTKCell

Also, even with the backwards pipeline and using a PythonSource to cast, vtkImageViewer2 doesn't seem to work:

[rexissimus]

7eade15 adds back the Instance port on VTKCell. I also cannot figure out how to use this. These modules are VTK classes and cannot be made into Spreadsheet Cells easily. They seem to be convenience classes for doing specific interactive things, so I am not sure they are really needed. @dakoop, do you have an idea how this should work?

[remram44]

If the module doesn't work and requires horrible regressions to exist, I suggest simply removing it. I am strongly opposed to your recent changes, they really take us back. Probably shouldn't be on master.

[rexissimus]

These are the affected classes:

• vtkRenderViewBase
• vtkExporter
• vtkImageViewer2
• vtkOpenGLExtensionManager
• vtkRenderer

I was finally able to get vtkExporter on the terminator:Isosurface pipeline to work by making it call methods last (you also have to set prefix first and then Write). Is this class not needed? Are there other ways to write data files? Can this be done with output modules yet?

If we can remove this, we can also remove:

• The Instance output on VTKCell
• The abstract VTKCell
• Using VTKCell as a port

[remram44]

I'd very much like to see output modules everywhere (yes, they do work) but they can probably come later.

• vtkRenderer definitely does not need a VTKCell input, we already have the AddRenderer port on VTKCell.
• I do not see vtkExporter.
• vtkRenderViewBase and vtkRenderView might not be useful?
• vtkOpenGLExtensionManager and vtkImageViewer2 seem unusable anyway.

[rexissimus]

vtkExporter is the parent class for several exporter classes. It looks like we would want to keep these. Should we try to create output modes for all of them? Should we ignore them for now and do this in a later release?

[remram44]

Exporting classes shouldn't need a spreadsheet object plugged into them. That doesn't make sense.

We definitely need the file-writing modules to work, be they output modules or not. How did it all work before?

[rexissimus]

cc @dakoop

Exporting classes shouldn't need a spreadsheet object plugged into them. That doesn't make sense.

The exporters seem to require a vtkRenderView which is what VTKCell wraps. My guess is using the VTKCell was the simplest way to access the view without having a separate module for this. Just append an exporter module on VTKCell and write the output. We could perhaps make the exporters take a vtkRenderer and create the view themselves offscreen or in a standalone window?

We definitely need the file-writing modules to work, be there output modules or not. How did it all work before?

They still work just like before. Except in details, like the abstract VTKCell modules that is needed because the spec does not support conditional ports.

[remram44]

There needs to be a way to export images from VisTrails without the need for the spreadsheet.

[vistrails-dev]

There need to be a way to export images from VisTrails without the need for the spreadsheet.

Does not vtkRendererToFile do that?

Also, I think VTKRenderOffscreen does the same thing and is probably redundant now?

The problem is the vtkExporter subclasses which can write different kinds of data from a vtkRendererView:
http://www.vtk.org/doc/nightly/html/classvtkExporter.html#details

[rexissimus]

VTKCell ports are removed by 2f38d55. vtkExporter classes now take a vtkRenderer module as input and create their own offscreen vtkRenderView. There are also upgrades to fix existing workflows.

[remram44]

I still see VTKCell; do I have to delete the vtk-spec-5_10_0.xml in .vistrails? Is that going to happen for every change in the VTK package's code?

[rexissimus]

Yes, i forgot to mention that. You are right, we should append the VTK package version to the filename so that it automatically gets recomputed for future versions of the VTK package.

[remram44]

Do you have an example that works? I connected vtkImageReader to vtkImageViewer2, but it doesn't produce any output at all. Should vtkImageViewer2 be simply removed?

[rexissimus]

Try vtkOBJExporter. Connect it to a vtkRenderer. Set "FilePrefix" first and then set "Write" to True.

I am not sure how vtkImageViewer2 works, it is probably not useful. I guess we could blacklist all affected classes except vtkExporter and vtkRenderer?

[rexissimus]

I found a working vtkImageViewer2 example:
Connect vtkJPEGReader(File="somefile.jpg") -> vtkImageViewer2

Different output types:

• call vtkImageViewer2.Render() to render in separate window.
• connect Render output to a vtkRenderView[Base] to render in separate window. This is not useful in vistrails, so they should be removed.
• connect Render output to a VTKCell to render in spreadsheet.

Having a VTKCell or vtkRenderer as input does not seem necessary for vtkImageReader2 so it has been removed.

VTKOpenGLExtensionManager requires a vtkRenderWindow and is used to add OpenGL extensions to a RenderWindow. This does not seem to fit in a vistrails workflow so I am removing it.

This is fixed in commit 9b8bc08.