VTK Algorithms in MeVisLab

Integration of VTK Algorithms in MeVisLab

This is the main documentation page for the binding of the VTK in MeVisLab.

See also

Integrating your own VTK classes

You can extend MeVisLab with your own VTK classes. Have a look at the VTKCPPExample module, how to do this. The example is located here:

Alternatively you can use the VTK wrapper generator that is shipped with MeVisLab, have a look at the ITKVTKGenerator module. NOTE: In many situations it is easier to just use the approach given in VTKCPPExample instead of using the generator.

Release Notes

Release Notes for MeVisLab 3.0

Release Notes for MeVisLab 2.6

  • Changes:
    • Help file layouts are in mhelp format now.
    • The directory structure of generated modules classes have same structure as other MeVisLab packages and manually developed and generated codes have been separated into different directories. Generated wrapper codes do not use old-style C-/C++-statements any more. Generated code and the 3rd-party VTK toolkit class binding have been made mostly C++-11 compliant.

Release Notes for MeVisLab 2.3

Release Notes for MeVisLab 2.2

Release Notes for MeVisLab 2.1

Release Notes for MeVisLab 2.0

Release Notes for MeVisLab 1.6

Release Notes for MeVisLab 1.5

Release Notes for MeVisLab 1.4

  • This installer uses vtk5.0 from the CVS repository from http://www.vtk.org. Note that no further VTK installer than MeVisLab1.4 VTKAddOn is required to be installed.

  • This installer for VTK modules requires MeVisLab version 1.4.

  • Note that some of the examples from VTK books, installer directories and data installers built as MeVisLab networks which can be found under MLabModulesstdAddOnsVTKMLVTKnetworks work fine but some of them still do not.

  • Improvements

    • A number of new classes have been wrapped and added by updating to vtk5.0. Also many classes have been fixed which were not functional in previous releases.
    • vtkRenderer is more stable and faster now, because it makes asynchronous updates to suppress renderings when many updates take place. It uses trackball interaction from now on which can be switched to older interaction mode with keys “j”, “i” and to trackball mode with “t”.
    • vtkContourFilter requires an interval of two values as Values parameter to make it possible to generate more than one contour. This probably requires updates of existing MeVisLab networks using this filter.
    • Most writer classes are functional now.
    • Many example networks have been improved.
    • A number of former undetected module parameters are available now.
    • New module VTKInputInfos added; it collects a number of information about the connected input class and provides often needed setting such as scalar range, number of points, cells etc. which then can easily be connected to other modules with field connections. Have a look at the example network for a use case.
    • New module VTKToMLImage which provides the symmetric operation to MLToVTKImage; now VTK image filtering can be embedded in ML module pipelines and vice versa.
    • A large number of minor bugs have been removed.
  • Known Issues

    • All currently available VTK modules in MeVisLab are still in Alpha or in Beta state. This includes especially the problems already mentioned in Release Notes for MeVisLab 1.3 (see below) and the following ones:

    • Actors and a few other modules do not have the UserMatrix parameter to specify the user transformation any more. It must be specified with a connected transformation module from now on to avoid conflicts between connected user transformations and the one specified as matrix. When loading networks stored in older versions this leads to warnings. Save and reload the network to remove warnings and connect a vtkTransform module to specify the user matrix if it is needed.

    • The following parameter fields are not initialized to their correct default values from the class instances:

      vtkCubeSource::Bounds, vtkAxisActor2D::Point1, vtkAxisActor2D::Point2, vtkDashedStreamLine::StartPosition, vtkExtractUnstructuredGrid::Extent, vtkFileOutputWindow::PromptUser, vtkGridSynchronizedTemplates3D::InputMemoryLimit, vtkGenericRenderWindowInteractor::EventPositionFlipY, vtkHyperStreamline::StartPosition, vtkImageCanvasSource2D::NumberOfScalarComponents, vtkImageCanvasSource2D::ScalarType, vtkImageDataGeometryFilter::Extent, vtkImageExtractComponents::Components, vtkImageFlip::FilteredAxes, vtkImageMaskBits::Mask, vtkImageMask::MaskedOutputValue, vtkImageViewer::Position, vtkImageViewer::Size, vtkImageViewer2::Position, vtkImageViewer2::Size, vtkLogLookupTable::Range, vtkMergeFields::NumberOfComponents, vtkOpenGLLight::DirectionAngle, vtkOpenGLVolumeTextureMapper3D::PreferredRenderMethod, vtkPlanesIntersection::Bounds, vtkPlanesIntersection::FrustumPlanes, vtkPlanes::Bounds, vtkPlanes::FrustumPlanes, vtkRenderWindow::NextWindowInfo, vtkRenderWindowInteractor::EventPositionFlipY, vtkRIBLight::DirectionAngle, vtkStreamPoints::StartPosition, vtkTextActor3D::Input, vtkVolumeTextureMapper3D::PreferredRenderMethod, vtkWin32ProcessOutputWindow::PromptUser, vtkWindowLevelLookupTable::Range, vtkXMLFileOutputWindow::PromptUser, vtkXYPlotActor::NumberOfLabels.

    • The following classes are internally not cleaned up completely on module deletes to avoid crashes. This leads to memory leaks.

      • vtkPolyData, vtkPlaneWidget, vtkRectilinearGrid, vtkSplineFilter, vtkStructuredGrid, vtkTextActor, vtkUnstructuredGrid, vtkXMLPImageDataWriter, vtkXMLPRectilinearGridWriter, and vtkXMLPStructuredGridWriter.
      • vtkImageViewer2 and vtkPlanesIntersection easily crash, for example when used without input data.
      • MLToVTKImage and VTKToMLImage still post warnings which can be ignored.
      • The vtkSTLReader has unknown problems to read files which leads to crashes sometimes.
      • A number of module post messages about non existing or required input connections; this often occurs, because connections are temporarily not available while creating or destroying networks. They can be ignored often. When they occur during normal operation it normally means a really missing or invalid connection.
      • A number of modules disappeared, often because they have been removed in updates from vtk4.4 to vtk5.0. This mostly affected hidden classes starting with “P” in name, for example, vtkPSphereSource. Mostly the corresponding public classes without “P” can be used instead. The following other classes also disappeared: vtkDistributedStreamTracer, vtkCutMaterial, vtkCollectPolyData, vtkDuplicatePolyData vtkExtractPolyDataPiece, vtkExtractUnstructuredGridPiece, vtkHierarchicalBox*, vtkMemoryLimitImageDataStreamer, vtkPassThroughFilter, vtkPieceScalars, vtkPiecewiseFunctionToPiecewiseFunctionFilter, vtkPushImageFiltersample, vtkRectilinearGridOutlineFilter, vtkTransmitPolyDataPiece, vtkTransmitUnstructuredGridPiece and some more classes.

Release Notes for MeVisLab 1.3

  • This installer uses vtk4.4. It can be checked out from the CVS repository from http://www.vtk.org. Note that no further VTK installer is required to be installed.

  • This installer for VTK modules requires MeVisLab version 1.3.

  • Note: Some of the examples from VTK books, installer directories and data installers built as MeVisLab networks which can be found under MLabModulesstdAddOnsVTKMLVTKExamples work fine but some of them still do not.

  • All currently available VTK modules in MeVisLab are in Alpha state. This includes especially the following problems:

  • Some modules do not provide all parameters of the corresponding VTK classes. Currently they are typically marked in the user interface of the modules with ?(N/A)? or simply do not appear. These parameters are of either complex nature, they are difficult to wrap or they are not useful for this implementation. For examples the following VTK types of parameters belong to them: Viewport, KeypressActivationValue, BasisFunction, BasisDerivative, array types and callback functions.

  • A number of VTK classes are wrapped as MeVisLab modules which, however, do not make sense. They will be removed in future versions. This affects especially modules from the categories Collections, Common, Windows and Widgets.

  • Some VTK modules still show errors in a parameter window or even on crash on usage or during deletion.

  • Module with a dynamic number of inputs or connections added with ?Add? methods are handled with a fixed number of three inputs. If this number of inputs is not sufficient then for properties the vtkAssembly or vtkPropAssembly modules can be used to collect a larger number of modules for one input.

  • Some module parameters are not initialized to the correct default value from the instance of the used VTK class. For example the following parameters are affected:

    vtkImageFlip::FilteredAxes, vtkImageGaussianSmooth::StandardDeviation, vtkImageGaussianSmooth::RadiusFactor, vtkCubeSource::Bounds, vtkImageMaskBits::Mask, vtkMergeFields::NumberOfComponents, vtkPlanes::Bounds, vtkXYPlotActor::NumberOfLabels, vtkDashedStreamLine::StartPosition, vtkExtractUnstructuredGrid::Extent, vtkGeometryFilter::Extent, vtkHyperStreamline::StartPosition, vtkImageDataGeometryFilter::Extent, vtkAxisActor2D::Point1, vtkAxisActor2D::Point2, vtkImageExtractComponents::Components, vtkImageMask::MaskedOutputValue, vtkImageViewer::Position, vtkImageViewer::Size, vtkImageViewer2::Position, vtkImageViewer2::Size, vtkInteractorStyleUnicam::WorldUpVector, vtkLight::DirectionAngle, vtkLogLookupTable::Range, vtkLookupTable::Range, vtkMPICommunicator::UseCopy, vtkOpenGLLight::DirectionAngle, vtkRenderWindow::Position, vtkRenderWindow::Size, vtkRenderWindow::WindowInfo, vtkRenderWindow::NextWindowInfo, vtkRenderWindow::ParentInfo, vtkRIBLight::DirectionAngle, vtkSharedMemoryCommunicator::UseCopy, vtkStreamPoints::StartPosition, vtkWin32OpenGLRenderWindow::Position, vtkWin32OpenGLRenderWindow::Size, vtkWin32OpenGLRenderWindow`::WindowInfo, vtkWin32OpenGLRenderWindow::ParentInfo, vtkWindowLevelLookupTable::Range, vtkImageMapper::CustomDisplayExtents, vtkOpenGLImageMapper::CustomDisplayExtents, vtkSpherePuzzleArrows::Permutation.