VTK/Rendering Update

This page attempts to summarize internal discussions and current directions with the VTK rendering update. The update to our rendering infrastructure involves several distinct types of rendering that have been identified as important, along with several key pieces of rendering infrastructure to accomplish these goals and lay the groundwork for the next decade. Please bear in mind that these plans are fluid, are being entered onto the VTK wiki for both wider dissemination and feedback before too much has been set in stone.

The main rendering targets can be roughly divided into three major areas:

• Volumes
• Polygonal geometry
• Glyphs and implicitly ray-traced geometry (e.g. spheres generated with fragment shaders)

The first two are likely familiar, glyph rendering has been present for quite some time, and implicit geometry is another approach that takes advantage of the parallelism on fragment shaders to generate smooth shapes for those that can be expressed mathematically. On the OpenGL side the major change is moving from the deprecated fixed pipeline of OpenGL 1.1 to the modern programmable pipeline where most rendering is performed on GPU resident buffers using vertex and fragment shaders.

Overview of Changes

Some of the major changes proposed are:

• Move to OpenGL 2.1 on the desktop, and OpenGL ES 2.0 on embedded systems
  • Use a common subset of APIs where possible to maximize code reuse
  • GL 2.1 is fully supported in recent versions of Mesa, Regal, and ES 2.0 on Angle
• Major shift from uploading single vertices to batching copies of geometry
  • Heavy use of vertex buffer objects, shaders, framebuffer objects
  • Provide hooks for interop with OpenGL or CUDA generated buffers
• Move to a rendering scene to enable more optimization
  • Ability to optimize rendering of large scenes
  • Minimization of state changes, coalescing draws
  • Advanced rendering techniques are easier to implement

Updating the rendering in VTK is a large undertaking, and will require shifts in how we perform rendering functions. It is also clear that we need a simpler, slimmer API where rendering can shift from tight loops with many branches to batched operations. It also becomes more important to support shared resources among OpenGL contexts, ideally shifting from a highly CPU-bound render loop to a highly GPU-bound render loop. The updates will make it simpler to add new OpenGL code to existing approaches, or override specific pieces.

Key Technologies

In order to minimize development time several libraries are being adopted, including Eigen for linear algebra and GLEW to handle extensions on the desktop. Newer libraries and abstractions such as Regal and Angle are also being examined in addition to Mesa to provide a wider number of systems where the OpenGL used for rendering can effectively be used. These choices are driven by previous experience in the VES and Avogadro projects which both explored approaches using scene graphs and more modern OpenGL APIs.