The MITK rendering model resembles the mechisms found in VTK. This section describes the core components for coordinating rendering processes and render windows. More...
Classes | |
| class | mitk::RenderingManagerFactory |
| Factory interface for facilitating the usage of a platform-specific mitk::RenderingManager instance. More... | |
| class | mitk::RenderWindow |
| mitkRenderWindow integrates the MITK rendering mechanism into VTK and is NOT QT dependent More... | |
| class | mitk::RenderWindowBase |
| Base class of MITK RenderWindows. More... | |
| class | mitk::vtkEventProvider |
| Integrates into the VTK event mechanism to generate MITK specific events. This class is NON-QT dependent pandon to the current MITK event handling code in QmitkRenderWindow. More... | |
| class | vtkMitkLevelWindowFilter |
| Applies the grayvalue or color/opacity level window to scalar or RGB(A) images. More... | |
Detailed Description
The MITK rendering model resembles the mechisms found in VTK. This section describes the core components for coordinating rendering processes and render windows.
Overview
To visualize a dataset it needs to be stored in the DataTree. Depending on the application, the whole DataTree may be displayed, or merely parts of it. The rendering of individual data items (e.g. volumes or polygon models) is conducted by specific Mappers: each kind of visualizable data has its own corresponding Mapper implementation (see Mapper Classes).
MITK is designed to intrinsically provide different views on data. For example, a volume dataset is volume rendered in a 3D view, and displayed slice-wise in a 2D view. A polygon model would be displayed as a contour in 2D (i.e., the intersection of the 3D model and the respective 2D plane). This principle applies to all kinds of data, thereby ensuring a consistent visual representation regardless of the view type. It is realized by providing Mappers for each combination of data type and view type. Every item of the DataTree is associated with a list of Mappers, each capable of rendering the data item in a specific view.
RenderWindows represent the rendering target: an area of the user interface into which data is rendered. The actual rendering process is controlled by Renderers, specifically by mitkVtkPropRenderer, which is a concrete implementation BaseRenderer and iterates over the elements of the DataTree to render each using the associated Mapper. Eeach data item of the DataTree has Geometry objects attached to it which describe the geometry of the data (e.g. its bounding box, location, or spatial conversion hints).
Encapsulating VTK Rendering Mechanisms
As a framework, MITK aims at making use of the visualization capabilities of VTK as much as possible. For the application developer building on top of MITK, the way of how to utilize specific VTK features should be straightforward and familiar. Therefore, most of the MITK rendering components closely resemble or integrate corresponding VTK components.
Just like VTK, MITK defines Renderers and Mappers. These classes do not derive from their VTK counterparts, but integrate them and have similar scopes of responsibility. While the VTK rendering mechanism is mainly focused on establishing a pipeline of rendering components (data, filters, mappers, and renderers), MITK has a central DataTree and provides convenient ways of rendering different items of the tree according to their type. Internally, the VTK rendering pipeline is used, though it is more hidden from the application developer who merely makes use of existing rendering capabilities.
As of MITK 0.8, the class vtkMitkRenderProp (a derivation of vtkProp) represents the single prop object in the VTK rendering pipeline responsible for coordinating the rendering of all objects in MITK's DataTree. The advantage of this approach is that all rendering management is done in the usual VTK rendering pipeline style, while the control of how data is actually rendered is entirely on MITK side. For example, MITK Mapper classes may either use VTK classes for rendering (actors, properties, ...), or do their rendering entirely in OpenGL where appropriate (e.g. in 2D Mapper classes). For further details refer to the page Rendering Concept.
Controlling it All: RenderingManager
On a higher level, all rendering in MITK is managed and supervised by the RenderingManager. Its main task is to provide a central instance where any part of the application can request a repaint of a particular RenderWindow. Thereby, requests can be issued from multiple independent subroutines at one time, and only result in one repainting call, rather than induce many unnecessary rendering passes.
Another task is the supervision of ongoing rendering activities. For large datasets, high quality rendering might become very slow and thus impede smooth user interactions. To alleviate this, level-of-detail rendering and abort-mechanisms are introduced and controlled by the RenderingManager to achieve interactive frame rate and response times. Note that these features are not yet available but currently under development.
The rendering process could be further simplified by making the DataTree automatically detect data changes that require the data to be re-drawn. The fundamentals for such a mechanism already exist but still for many modifications a repainting request has to be issued by the entity causing it.
Platform-Specific Implementation
MITK tries to integrate seamlessly into the normal VTK rendering pipeline. The whole MITK data(tree) is capsuled into one customized vtkProp, the so-called vtkMitkRenderProp which is then integrated into VTK pipeline.
The VTK integration into GUI systems, like e.g. QT, is therefore equal to normal VTK usage. As an example, the MITK MainApp requires the QT-VTK widget (provided by VTK) for integration of renderWindows into GUI. Further information on this can be found in section "Related Pages" "Rendering in MITK by means of the QT-VTK widget".
