VTK/MultiPass Rendering: Difference between revisions

From KitwarePublic
< VTK
Jump to navigationJump to search
Line 15: Line 15:
* [http://www.vtk.org/doc/nightly/html/classvtkRenderState.html vtkRenderState]
* [http://www.vtk.org/doc/nightly/html/classvtkRenderState.html vtkRenderState]
* [http://www.vtk.org/doc/nightly/html/classvtkSequencePass.html vtkSequencePass] (allow run-time combinations of passes)
* [http://www.vtk.org/doc/nightly/html/classvtkSequencePass.html vtkSequencePass] (allow run-time combinations of passes)
The gut of vtkRenderPass is to perform some rendering based on some render state. The central method is
<pre>
virtual void Render(const vtkRenderState *s)=0
</pre>
Any concrete subclass will implement this method.
vtkRenderState aggregates information necessary for the render pass to perform rendering. The states consists of:
* the vtkRenderer (which gives access to the vtkCamera, to the vtkRenderWindow and to the vtkProps)
* the list of props to render (it is a subset of the props on the renderer, usually the visible props that remain after the frustum culling operation) <i>A RenderPass may ignore this cached list because it is not relevant for it and may work again directly on all the props from the Renderer. The typical example is a shadow mapping pass, that will change the active camera to be one of the
light, so culling from the original camera does not make sense and will produce wrong result.</i>
* the current framebuffer in use, as some passes can render in vtkFrameBufferObject, not only on the framebuffer provided by the vtkRenderWindow.
* a list of required property keys that have to be present on the props. <i>this is a way to filter props to render</i>


= Elementary passes =
= Elementary passes =

Revision as of 20:11, 19 June 2009

WORK IN PROGRESS

Overview

Modifying the logic of the rendering pipeline of VTK is cumbersome: it requires to modify several existing classes, and often requires a full understanding of most of the rendering classes. Modifying the rendering logic is really sensitive and error-prone. It's easy to break the code. More importantly, it also means that it is impossible from an external project to modify the rendering pipeline.

The multi-pass rendering framework try to address these issues by providing a hook in the vtkRenderer class where you can plug your own rendering algorithms (passes) and combine them with other algorithms at compile-time (statically) or a run-time (dynamically).

The approach is, even if the VTK source code is freely available (published under a (non-copyleft) free software license), to think of it as a closed-source package and see how it could be extended by relying only on its public API.

Fundamental classes

The following classes are the building blocks of the multi-pass rendering framework:


The gut of vtkRenderPass is to perform some rendering based on some render state. The central method is

 virtual void Render(const vtkRenderState *s)=0

Any concrete subclass will implement this method.

vtkRenderState aggregates information necessary for the render pass to perform rendering. The states consists of:

  • the vtkRenderer (which gives access to the vtkCamera, to the vtkRenderWindow and to the vtkProps)
  • the list of props to render (it is a subset of the props on the renderer, usually the visible props that remain after the frustum culling operation) A RenderPass may ignore this cached list because it is not relevant for it and may work again directly on all the props from the Renderer. The typical example is a shadow mapping pass, that will change the active camera to be one of the

light, so culling from the original camera does not make sense and will produce wrong result.

  • the current framebuffer in use, as some passes can render in vtkFrameBufferObject, not only on the framebuffer provided by the vtkRenderWindow.
  • a list of required property keys that have to be present on the props. this is a way to filter props to render

Elementary passes

Existing passes

The following classes are provided with VTK. The key is they could have been written out of VTK. It demonstrates that you can customize and extent the rendering VTK pipeline in an external project without modifying VTK:

Parallel rendering