VTK 6.0 Upgrade

Upgrade Overview

Building VTK

  • New Modular system.
  • Can turn on/off Module groups or individual modules.
  • Turning a group OFF makes available the modules comprising that group for individual selection.
  • Not all modules belong to a group.
  • It appears VTK_Group_Rendering and VTK_Group_StandAlone are the only groups turned on by default.
  • Turning on a single module will also turn on any modules it depends upon.

Available groups:

  • VTK_Group_Imaging
  • VTK_Group_MPI
  • VTK_Group_Qt
  • VTK_Group_Rendering
  • VTK_Group_StandAlone
  • VTK_Group_Tk
  • VTK_Group_Views

Setting VTK_Group_StandAlone:BOOL=false, turns off modules such as:

  • Module_vtknetcdf
  • Module_vtkhdf5
  • Module_vtkexodusII

There are many more modules part of the StandAlone group. In the current VTK build system there is no way to specify a "system" NetCDF or ExodusII library to use instead of the builtin, so turning off the StandAlone group may be the most efficient way to accomplish what our VTK-5.8 build hacks ("VTK_USE_NETCDF" and "VTK_USE_EXODUS") do with minimal effort. Determination of StandAlone modules needed for VisIt will have to be made(eg Module_vtkhdf5 in conjunction with VTK_USE_SYSTEM_HDF5).

If we want to turn off all groups and build only the modules we need, here's a minimal beginning list:

  • Module_vtkCommonCore
  • Module_vtkFiltersFlowpaths
  • Module_vtkFiltersHybrid
  • Module_vtkFiltersModeling
  • Module_vtkInteractionStyle
  • Module_vtkIOLegacy
  • Module_vtkIOPly
  • Module_vtkIOXML
  • Module_vtkRenderingAnnotation
  • Module_vtkRenderingFreeType
  • Module_vtkRenderingFreeTypeOpenGL
  • Module_vtkRenderingOpenGL

VisIt Build System Changes


  • For install macros, need to account for VTK library names now including version, eg vtkCommonCore-6.0.so
  • VTK's python modules now also include Python's major-minor version, eg vtkCommonCorePython27D-6.0.so

There appears to have been a change in how vtk libs are linked with an application (caveat: only tested on Windows with MSVC):

target_link_libraries(myApplication vtkCommonCore)

If doing a debug build, wants to link with the debug version of vtkCommonCore. This may be resolveable with a VTK build and/or install setting.

  • I can fix this by copying (in the install dir) VTKTargets-release.cmake to VTKTargets-debug.cmake and changing 'Release' to 'Debug' and 'RELEASE' to 'DEBUG' throughout.

VTK recommends adding this:


However, it is a bit heavy-handed, adding to every VisIt Target:




Both of these are already added to VisIt's targets that link with VTK, so the same approach should be used for the new


that are part of the UseVTK.cmake.


I was initially unable to build against Eric's VTK. The file /usr/gapps/visit/thirdparty_shared_2_6_0/vtk/6.0_12_01_04/linux-x86_64_gcc-4.4/lib/cmake/vtk-6.0/VTKConfig.cmake contained an include that I could not access at line 47. This seems like a bug in VTK's install to put a hardwired path to a build location in a final configuration file. I solved the problem by commenting out the include.

# Load testing interface macros.

API / Pipeline Changes

There were several features deprecated in VTK 5.0 that were still supported, but have now been eliminated. These include:

  • vtkTypeRevisionMacro has been replaced with vtkTypeMacro.
  • vtkCxxRevisionMacro has been removed. It can just be removed from the code.
  • vtkDataObject->Update has been removed. It should be replaced by calls to Update on the filter (algorithm) creating the object.
  • filter->SetInput has been replaced by either
    • filter->SetInputData(vtkDataObject)
      • Most common use-case in our execution model
      • This does not create a pipeline connection (will this cause a problem for us?)
    • filter->SetInputConnection(vtkAlgorithmOutput)
      • sets up a pipeline connection.
      • The vtkAlgorithmOutput argument can be obtained from another filter via filter->GetOutputPort()
      • In the case of filter->SetInput(this->GetInput()), can change to filter->SetInputConnection(this->GetInputConnection(0,0))
      • Our filters that create internal pipelines can use this
  • vtkMappers now have a 'Static' flag, that prevents propagation of updates down the pipeline. Used if data never changes.

All the classes of the form vtkXXXToYYYFilter have been replaced with vtkYYYAlgorithm. The output type of the vtkYYYAlgorithm is YYY and the input is by default also YYY. If the input type is different from the output type then the method FillInputPortInformation must be defined to set the appropriate input type. The following changes need to be made:

  • Replace vtkPolyDataToPolyDataFilter with vtkPolyDataAlgorithm
  • Replace vtkDataSetToDataSetFilter with vtkDataSetAlgorithm
  • Replace vtkUnstructuredGridToPolyDataFilter with vtkPolyDataAlgorithm
  • Replace vtkDataSetToPolyDataFilter with vtkPolyDataAlgorithm
  • Replace vtkRectilinearGridToPolyDataFilter with vtkPolyDataAlgorithm
  • Replace vtkStructuredGridToPolyDataFilter with vtkPolyDataAlgorithm
  • Replace vtkDataSetToUnstructuredGridFilter with vtkUnstructuredGridFilter
  • Replace vtkUnstructuredGridToUnstructuredGridFilter with vtkUnstructuredGridFilter

Here are the changes that need to be made to header file using vtkPolyDataToPolyDataFilter as an example:

  • Replace vtkPolyDataToPolyDataFilter with vtkPolyDataAlgorithm
  • Replace
virtual void Execute();


virtual int RequestData(vtkInformation *,
                        vtkInformationVector **,
                        vtkInformationVector *);
  • If present replace
virtual void ComputeInputUpdateExtents(vtkDataObject *output);


virtual int RequestUpdateExtent(vtkInformation *,
                                vtkInformationVector **,
                                vtkInformationVector *);
  • If necessary add
virtual int FillInputPortInformation(int port, vtkInformation *info);

Here are the changes that need to be made to source file using vtkPolyDataToPolyDataFilter as an example:

  • Add
#include <vtkInformation.h>
#include <vtkInformationVector.h>
  • Change


    vtkInformation *vtkNotUsed(request),
    vtkInformationVector **inputVector,
    vtkInformationVector *outputVector)
    // get the info objects
    vtkInformation *inInfo = inputVector[0]->GetInformationObject(0);
    vtkInformation *outInfo = outputVector->GetInformationObject(0);

    // Initialize some frequently used values.
    vtkPolyData  *input = vtkPolyData::SafeDownCast(
    vtkPolyData *output = vtkPolyData::SafeDownCast(
  • If the input is other than vtkPolyData then you need to add the following method with the appropriate type.
vtkClass::FillInputPortInformation(int, vtkInformation *info)
    info->Set(vtkAlgorithm::INPUT_REQUIRED_DATA_TYPE(), "vtkDataSet");
    return 1;
  • If present, change
vtkSource::SetNthOutput(1, p);


this->GetExecutive()->SetOutputData(1, p);

and add

#include <vtkExecutive.h>
  • If present, change
return (vtkPolyData *) vtkSource::GetOutput(0);


return vtkPolyData::SafeDownCast(

and add

#include <vtkExecutive.h>
  • If present, change


  • If present, change
vtkClass::ComputeInputUpdateExtents(vtkDataObject *output)


    vtkInformation *request,
    vtkInformationVector **inputVector,
    vtkInformationVector *outputVector)
    this->vtkPolyDataAlgorithm::RequestUpdateExtent(request, inputVector,

    // get the info objects
    vtkInformation *inInfo = inputVector[0]->GetInformationObject(0);
    vtkInformation *outInfo = outputVector->GetInformationObject(0);

    vtkPolyData  *input = vtkPolyData::SafeDownCast(
    vtkPolyData *output = vtkPolyData::SafeDownCast(

Mangled Mesa

VTK dropped Mangled Mesa support, this was the solution we used to create one set of libs and binaries that could leverage both a hardware (system gl) and software (mesa) for rendering.

OSX and Windows provide an offscreen GL contexts which VTK can use, moving forward we need a non-mangled mesa solution for linux/unix platforms.

After discussing our options, we arrived with three primary paths forward:

  • Dynamic Loading via LD_LIBRARY_PATH

Build VTK linking to system gl, build a standard offscreen mesa. For the software case, set LD_LIB_PATH to use Mesa's GL, and use OSMesa inside of VisIt to create a OSMesa rendering window. This approach requires the least amount of changes to VisIt, but has some ABI risk.

  • Build two engines.

This is similar to paraview's approach of building multiple versions for different rendering back-ends. If we follow this path, we don't want a multiple visit build solution. We would the extra targets and linking into our CMake logic. This would require building two versions of VTK, there is some concern that Find VTK CMake logic may be tough to control in this case.

  • Dynamic loading via GLEW.

We have this partially implemented in VisIt by Tom Fogal. It doesn't appear that Tom's changes to support dynamic loading of the GL libs made it back into the official GLEW source. So we have an unmaintained path, and we don't have access to Tom's time. We could use a modified GLEW it at as a complete stand in for GL (Build VTK linking to GLEW, as GL) but this would require a lot of development effort. It could evolve into elegant solution, but there are currently many rough edges.

Basic Plan

We are going to try the first option, Dynamic Loading via LD_LIBRARY_PATH

  • Avoid explicit linking of OpenGL in avt libs and engine plugins.
  • Avoid linking X11 in the engine
  • IF mesa is selected, we will use a small lib that provides the Mesa Render Window and a VTK Factory that allows us to override the default X Render Window.
  • For dynamic Loading via LD_LIBRARY_PATH, we may need to set the linker to ignore unlinked symbols.
    • gcc: SET(CMAKE_EXE_LINKER_FLAGS "-Wl,--unresolved-symbols=ignore-all")
  • We may not need to use Dynamic Loading, it may suffice to simple link as follows:
    • The viewer exe will link with System GL
    • The engine exes will link with MesaGL or System GL dependant on the selection / presence of mesa.

Test Suite

Kat's Notes: Some issues I've noticed in the test suite (besides the obvious failures due to not using Mesa currently): Note also, I am working from a Debug version of vtk.

  • Transparency differences, the 'current' images appear to be more color-saturated (or perhaps that is the wrong description for the differences)
  • Some plots appear to be 'flipped', as if looking at them from the opposite z direction. See ticket #1347
    • plots/curve.py: results 2_*, the Pseudocolor plot portion.
    • hybrid/math_expr.py: results 02
  • Tensor glyphs not being coloured correctly.
    • plots/label.py: results 7_*
    • plots/tensor.py: results 01, 02, 03
    • I played with setting backface/frontface colors and setting ScalarVisibility to OFF. Had to also play with lighting, but then the 'black' glyphs changed color to the backface color. So it appears some of the glyphs are 'inside-out'.
    • Made same changes with 2.6, but we get the 'inside-out' glyphs colored with backface color without any lighting manipulation, so the change is in how backface is rendered or with lighting with the new vtk.
    • databases/mili.py: results 23-25
  • Label plots with depth testing (depthTestMode = LABEL_DT_AUTO)
    • plots/label.py: results 8_*
  • rendering/legends.py, crashing setting fonts
    • I cannot get it to crash using similar steps through gui.
    • Using Totalview, appears to be a problem with FTGL, called from some cleanup code in vtkFreeTypeUtilities.


Kitware VTK 6 Wiki

Kitware VTK 6 Build System Migration Notes

VTK-5.8 Manual

VTK-6 Manual

February Code Sprint Planning

Development Tasks

I created a branch called VTK-6 and you can check it out using the following command:

co_branch VTK-6 src -user bonnell

If you modify some code and aren't sure it is correct or if it needs to be modified later, you should comment it with the following so that it can easily be found.

// FIX_ME_VTK6.0

The following should be used to wrap C++ code that only compiles on VTK 6.0.


The following should be used to wrap CMake code that only compiles on VTK 6.0. This doesn't work in the config-site files but it should work in all but the top level CMakeLists.txt files.

Issue Description Developer Status
Figure out issues in vtkqt directory compiliing on Linux. Currently the vtkqt directory doesn't compile because the X headers are not getting defined on Linux. There is also the issue of switching to the latest versions of the files from VTK 6.0, since they are pretty much copied from VTK. See the README file in the directory for a description of why. Kathleen Done
Convert the plot plugins to use vtk 6.0. Fix the compile issues with the plot plugins. Kathleen Done
Convert the operator plugins to use VTK 6.0. Fix the compile issues with the operator plugins. Eric Done
Convert the database plugins to use VTK 6.0. Fix the compile issues with the database plugins. With our present configuration, we are not attempting to build: MDSplus, StreamGhostTest, ViSUS. Mark Done
Enable MANTA and fix compile issues in avt. Currently MANTA is disabled because there are some compile errors in avt relating to MANTA rendering. Kathleen Done
Enable XDMF and fix compile issues. Currently XDMF is disabled because of compile issues. Brad Done
Modify build_visit to build VTK 6.0. We should modify build_visit to build VTK 6.0. We should grab a version from the VTK development trunk, add it to the third_party directory, and modify build_visit to build it. We should start with the parameters that Kathleen used in her VTK build. Brad Done
Modify build_visit to build a non unmangled mesa. Mangled mesa is not supported in VTK 6.0 so we need to use a non mangled mesa for scalable rendering on Linux. Build_visit should be modified to optionally build an non mangled mesa. This will become the default after the upgrade. Brad Done
Modify visit to not use mangled mesa for scalable rendering on Linux. Mangled mesa is not supported in VTK 6.0 so we need to use a non mangled mesa for scalable rendering on Linux. The non-mangled mesa needs to be used only by the engine for doing scalable rendering. This can be done by changing the LD_LIBRARY_PATH to point to mesa instead of GL when running the engine on Linux. Cyrus pending
Remove use of mangled mesa. Once we have VisIt modified to work without mangled mesa, we can remove all the mangled mesa coding. unassigned pending
Remove use of GLEW. Once we have VisIt modified to work without mangled mesa, we can remove all the GLEW coding. unassigned pending
Enable vtkPythonWrappers Handle any build / install changes related to vtk Python wrapping. Kathleen pending
Fix FindVisItVTK.cmake The setup install portion isn't working, and Python version is hard coded. Kathleen Done
Make at pass at compiler warnings We've talked about this in prep. for a major release. Maybe now isn't the best time but I thought I would mention it. unassigned pending
Verify our xml generators still work correctly. For example, xml2cmake may need to be updated to add correct vtk libs. unassigned pending
Evaluate our ReleaseData strategy. Most often in this method, we set an internal vtk filter's input to NULL, create an empty vtkDataSet and set the filter's output to this empty data set. Is this still valid in light of the new vtk, where setting a filter's 'InputData' doesn't create a pipeline connection anyway? unassigned pending
Ghost zone removal not working. I created a pseudocolor plot of d from curv2d.silo, which has ghost zones and the ghost zones are being plotted. The extents are correct, so the ghost zones are being taken into account in the extents calculation. The problem is only with the Pseudocolor and Truecolor plots. The rest of the plots appear to be correct. Looking at the code, the avtGhostZoneFilter passes the ghost zones through for those plots and relies on the mapper to remove them. Kathleen Done
Remove FIX_ME_VTK6.0 comments. Remove any vtk-6 fix me related comments in source code unassigned pending
Fix the Exodus reader. Some of the Exodus tests in the regression suite fail. The reader should be modified so that they pass. Mark pending

build_visit command line

Here's the command line I'm using at LC:

 env PAR_COMPILER=/usr/local/bin/mpicc ./build_visit --group visit --console \
     --thirdparty-path /usr/gapps/visit/thirdparty_shared_2_7_0 --all-io \
     --makeflags -j12 --svn --no-visit --parallel --no-adios --hdf4 --itaps \
     --mili --manta --mesa