Views And Representations: Difference between revisions
(Created page with '<font color="red">UNDER CONSTRUCTION</font> ==Background== Views and their consorts, representations, have been the most complex components of the ParaView visualization pipeli…') |
No edit summary |
||
| Line 43: | Line 43: | ||
mapper/actor). In AddToView() it adds the actor to the View's renderer. And | mapper/actor). In AddToView() it adds the actor to the View's renderer. And | ||
that sums it up. The view before every render calls Update() on all | that sums it up. The view before every render calls Update() on all | ||
representations and then triggers a render -- plain and simple. | representations and then triggers a render -- plain and simple. This breaks down | ||
for complex views like the RenderView which supports rendering on different | |||
processes. We still can use this single pass setup for client-only views or view | |||
that do rendering at a fixed location. | |||
==If only life was easy!== | ==If only life was easy!== | ||
| Line 56: | Line 59: | ||
processes, then it will have valid input on some and nothing connected to the | processes, then it will have valid input on some and nothing connected to the | ||
input on other nodes. A representation is responsible for converting the data to | input on other nodes. A representation is responsible for converting the data to | ||
representable form. Thus a surface- | representable form. Thus a surface-representation will possibly convert an | ||
unstructured grid to polydata shell so that it can be rendered. Now this can | unstructured grid to polydata shell so that it can be rendered. Now this can | ||
only be done in RequestData(). The view may need to know the geometry sizes to | only be done in RequestData(). The view may need to know the geometry sizes to | ||
| Line 81: | Line 84: | ||
information is provided by the View (FIXME). | information is provided by the View (FIXME). | ||
==REQUEST_INFORMATION== | ==REQUEST_INFORMATION: Provide information to the View== | ||
Revision as of 08:10, 11 October 2010
UNDER CONSTRUCTION
Background
Views and their consorts, representations, have been the most complex components of the ParaView visualization pipeline. This wasn't without merit, ParaView rendering framework is indeed quite flexible and powerful, working without issues (for the most parts :) ) in different configurations and customizations.
The concept of Views and Representations is pretty simple really. A View is an abstraction that can "show" data, and Representation is an abstraction that can present/format the raw data so that it can be "shown" in the view. How the data is shown? Is it rendered as polygons in an OpenGL window or as a list of values in a QTableWidget are immaterial. At the end of any visualization pipeline, you have data that needs to be "shown" and representations and views do that for you.
This notion was found so useful that we now have views and representations in VTK itself. vtkDataRepresentation is a vtkAlgorithm subclass, a sink to be more precise. One simply connects a data source to the representation's input and dumps it in a view and voila! You have a display for your data.
vtkView, vtkDataRepresentation and their subclasses have been maturing over the past year or so in VTK repository. ParaView meanwhile has its own ServerManager level view-representation infrastructure which developed parallel to VTK's and has similar overtones but with the added backbone to support parallel rendering and client-server operations.
Besides being parallel VTK's views and representations, the main difficulty with ParaView's views/representations has been its complexity and poor readability. This was due to the large number of components involved as well as the fact that coding complex pipelines in ServerManager is much harder to debug and follow when compared with the same pipeline in VTK level.
So we decided to add new VTK-based views and representations that could leverage ParaView's parallel infrastructure for interprocess communication without adding complexity in the ServerManager level.
VTK-based Views And Representations
In brief, vtkDataRepresentation is vtkAlgorithm with no output ports. In RequestData() stage, sets up the internal rendering pipeline (typically mapper/actor). In AddToView() it adds the actor to the View's renderer. And that sums it up. The view before every render calls Update() on all representations and then triggers a render -- plain and simple. This breaks down for complex views like the RenderView which supports rendering on different processes. We still can use this single pass setup for client-only views or view that do rendering at a fixed location.
If only life was easy!
As just described, all the view does is update the representation and then render. Now this works well when you actually have data pipelines (or trivially when the representation doesn't need any input). Now in ParaView world, expecting the data to be present is not a legitimate expectation. The data pipelines in only on the data-server, while the rendering components need to render either on the data-server itself, or render-server or client (based on configuration and settings). So if we assume that the vtkDataRepresentation is instantiated on all processes, then it will have valid input on some and nothing connected to the input on other nodes. A representation is responsible for converting the data to representable form. Thus a surface-representation will possibly convert an unstructured grid to polydata shell so that it can be rendered. Now this can only be done in RequestData(). The view may need to know the geometry sizes to decide where to render on server or client, for example. The view should now make that decision and send it to all representations so that they can then deliver the geometry to the right node where rendering is going to happen. Plus there's ordered compositing, which may require the geometry to be redistributed. This explanation hopefully makes it clear that we need more passes for the representations after the traditional pipeline passes, and we need mechanism to communicate various parameters from views to representations such as the rendering-location decision.
ParaView View Passes
A ParaView view, will go thorough following passes during each render. A representation is expected to do certain tasks in each of these passes. These are described next.
UPDATE PASS: vtkAlgorithm passes and RequestData
First pass is called vtkAlgorithm::Update() on the representations. Thus results in all the traditional algorithm passes. In RequestUpdateExtent() the representation should setup piece/time request. ViewTime and partition information is provided by the View (FIXME).
