The VTK development team is happy to announce that VTK 6.2.0 is ready. Special thanks go out to everyone who tested and provided input and fixes during the release candidate cycle. You can find the source, data, and vtkpython binary packages here:

VTK’s use of the parallelism available in modern architectures continues to mature. To set the stage for this move, we have refactored how pieces and extents are handled in the pipeline. The pipeline used to inject extent translators into the pipeline to obtain structured sub-extents for each requested unstructured piece. This approach had flaws so now the translation responsibility falls to the readers which are best able to make the computation and parallel filters are now responsible for dealing gracefully with unexpected extents. Next we have updated to the latest version of the Dax toolkit and begun to lay the groundwork for adopting the vtk-m project as a successor to the Piston, Dax, and EAVL efforts. There have  been a series of minor improvements to the SMP framework and vtkSMP filters too as we get ready to adopt them in a large swath of VTK’s algorithms. In related work, note that we have begun to support Xeon Phi chips.

Support for the Web continues to improve in this release as well. VTK-Web has migrated to WAMP 2.0 in 6.2 and there are now complete and updated examples of using the web launcher to start vtkweb applications. vtkWeb applications now support http-only server/client configurations for situations when websockets are not acceptable. There were also improvements made to VTK to support the creation and use of Cinema and Workbench applications (in-situ deferred visualization) that are described in the SuperComputing 2015 paper “An Image-based Approach to Extreme Scale In Situ Visualization and Analysis”

Wrapped languages have gotten a share of the attention in this release. There have been several fixes for ActiViz.Net which was recently updated from 5.8 to VTK 6.1 and will soon be updated again to 6.2. The Tcl examples have finally been upgraded following modularization and note that it is now mandatory to invoke the method Start on the instance of vtkRenderInteractor from Tcl. In Java, vtkPanel’s behavior was changed to better support advanced class loader system like OSGI. VTK’s dashboards now automatically build redistributable packages on Windows, Linux and Mac that will allow us to feed Maven.

Python has received the heaviest dose of updates. Wrapped namespaces and enum types are now available in Python. We’ve also made significant improvements to the VTK-numpy integration by introducing a number of Python modules that provide numpy-compatible interfaces to VTK data structures. We’ve also introduced vtkPythonAlgorithm, which makes it easier than ever to quickly extend VTK with filters that are written directly in Python. We also improved the python support for callback with calldata. In case there is a “CallData” value associated with an event, in C++, you have to cast it from void* to the expected type using reinterpret_cast. The equivalent in python is now to set a CallDataType attribute on the associated python callback.

VTK’s rendering is making both evolutionary and revolutionary advances in this release. The evolutionary changes include the usual number of incremental improvements. These include such things like advanced color and display controls, “sticky” axes mode for vtkCubeAxesActor, out of range color assignments, and indexed color lookups for vtkStringArrays. There are also a number of text rendering improvements such as better multiline, rotated, and aligned text along with new BackgroundColor and BackgroundOpacity options.

The revolutionary changes can be found in the OpenGL2 modules. These are under active development at the moment, and the API is subject to change in the next release, but early adopters are encouraged to preview it and report their experiences with it on the mailing list. OpenGL2 is a rewrite of VTK’s rendering backend that brings VTK up to date with modern OpenGL programming practices. By replacing antiquated rendering techniques with modern ones, we offload work to the GPU more effectively and have increased rendering performance by orders of magnitude with large numbers of primitives. This work, funded by the NIH VTK Maintenance grant touches both surface rendering and volume rendering visualizations.

The new OpenGL2 backend also supports OpenGL ES 2.0 and 3.0 — versions found in Android and iOS devices. In general, support for mobile architectures has been greatly improved. There are now CMake flags, VTK_IOS_BUILD and VTK_ANDROID_BUILD, which give the user a simplified set of options relevant to building the VTK iOS framework and Android libraries, respectively. Rather than have to manage a series of VTK builds, these options consolidate cross-compiling for mobile architectures into a single configuration and build step.

Another direction that VTK is heading into is providing external rendering support, more specifically for immersive environments. A new module is added to VTK that allows using VTK’s vast array of classes in external OpenGL environments. This effort allows developers to couple VTK’s scientific visualization capabilities with virtual reality applications such as VRUI, FreeVR, etc.

Besides the above progress some of the most notable changes in VTK 6.2 include

  • deprecated InfovisParallel

  • Xdmf3 – ARL’s next generation HDF5 backed file manipulation library

  • added a reader and writer for NIfTI files, including the 64-bit NIfTI-2 format

  • added support for SpaceMouse devices

  • removed -fobjc-gc from VTK_REQUIRED_OBJCXX_FLAGS

  • Rewrote the OS X Cocoa mouse event handling code to make it more robust

  • hdf5 package shipped with VTK was upgraded to version 1.8.13

  • added a mode to vtkScalarsToColors where scalars are directly used as colors

We hope you enjoy this release of VTK! As always contact Kitware and the mailing lists for assistance.

9 comments to VTK 6.2.0

  1. Are there plans to support vtkGUISupportQtOpenGL with OpenGL2 rendering backend, i.e. create vtkGUISupportQtOpenGL2?

    We currently use QVTKWidget2 with my application, and this module is missing when using OpenGL2 backend.

    Also vtkGenericOpenGLRenderWindow no longer exists when using OpenGL2 backend, are there plans to create vtkGenericOpenGL2RenderWindow?

  2. Yes and yes. The plan is for OpenGL2 to become the default option and for OpenGL1 to be removed. We probably just missed those two classes. Please file bug reports at to help us remember to fix them. If you ask on the mailing list, someone will likely have a work around for 6.2.0.

  3. can you provide detailed steps to build for ios. I am having problem in building for ios using above information.

    1. I would suggest using a newer version of VTK as they have better iOS support. If that fails please post on the vtkusers mailing list with the details of what failed, error messages etc.

        1. Thanks a lot Ken for the pointer..
          I tried all possible debug options, but, at the end, the required VTK_framework is not getting generated.
          Does the link given by you contains the framework and that is downloadable ?

  4. I am planning to incorporate the VTK toolkit in my ios app. Is there any tutorial where I can learn how to integrate this framework in ios application?

Leave a Reply