VTK/MultiPass Rendering With IceT: Difference between revisions

From KitwarePublic
< VTK
Jump to navigationJump to search
No edit summary
Line 189: Line 189:
</source>
</source>


This example illustrates how to use vtkIceTCompositePass. vtkIceCompositePass a vtkRenderPass subclass that uses IceT for compositing. When instantiated across different processes, it ensures that a composite result is available in the active render buffer on the root node (or the tile-result on all node in tile-display mode). If not in tile-display mode, then the active buffer on that node ends up with the result of the rendering of the data available on that processes, which may be partial depending on your pipeline.
==vtkIceTCompositePass==
 
The above example illustrates how to use vtkIceTCompositePass. vtkIceCompositePass a
vtkRenderPass subclass that uses IceT for compositing. When instantiated across
different processes, it ensures that a composite result is available in the
active render buffer on the root node (or the tile-result on all node in
tile-display mode). If not in tile-display mode, then the active buffer on that
node ends up with the result of the rendering of the data available on that
processes, which may be partial depending on your pipeline.
 
vtkIceCompositePass has API to indicate if we are to treat the setup as a
tile-display i.e. treating all nodes as if they form a large display and then
only show the tile from this large display that corresponds to this process.
 
If data is replicated on all nodes, you may consider setting
vtkIceCompositePass::DataReplicatedOnAllProcesses to true, which avoids
unnecessary compositing.
 
Whenever translucent geometry or volume rendering is involved, one needs to
ensure that a KdTree which can be used to generate an order for
ordered-compositing is provided. This may require that you redistribute that
data so that a KdTree can be generated. You may want to look at
vtkDistributedDataFilter for redistributing data.
 
vtkIceCompositePass works on active frame buffer, just like any other
vtkRenderPass. Hence, if you want apply additional passes such as say Sobel edge
detection or Gaussian blur, you can add the vtkIceCompositePass as the delegate
pass for vtkSobelGradientMagnitudePass or vtkGaussianBlurPass. Of course,
except in tile-display mode, all nodes execept the root will we processing
partial results (if data is distributed).

Revision as of 20:09, 29 July 2010

OverView

Since VTK 5.6, a multi-pass rendering framework was ad to support rendering techniques that require multiple passes such as rendering shadows using shadow maps. Recently we extended the framework to enable use of IceT (Image Composition Engine for Tiles) for compositing. This makes it possible to write Parallel VTK code that renders on tile-displays or client-server configurations while using multi-pass rendering framework.

This document discusses the various classes involved and some example implementations added to the VTK/ParaView repository.

VTK or ParaView?

At the time of writing of this document the IceT source is included in ParaView and not VTK. Hence some IceT specific classes are in ParaView repository. However, we have plans to move IceT to VTK itself. Once that happens, these classes will move to VTK as well and one would have have to bring in ParaView for writing VTK-based examples using IceT.

All examples developed don't rely on any ParaView code except to bring in IceT libraries.

Things you should know before you start writing multi-process code

This article is of interest only to those who are writing parallel rendering code. All the onus of creating sensible visualization as well render-pass pipelines on all processes lies on the developer. We provide a collection of classes that aid in ensuring the that windows/renderers/cameras are synchronized among all processes. But the developers has to employ these classes and set them up correctly.

Simplest Case: Render a Sphere in Parallel

Here's a simple example that renders a distributed sphere in parallel using IceT.

<source lang="cpp"> // A simple example that demonstrate how to use the vtkIceTCompositePass and // supporting classes to render a sphere in parallel. // This only uses the minimal set of functionality and hence does not support // opacity < 1.0.


  1. include "vtkActor.h"
  2. include "vtkCamera.h"
  3. include "vtkCameraPass.h"
  4. include "vtkIceTCompositePass.h"
  5. include "vtkLightsPass.h"
  6. include "vtkMPIController.h"
  7. include "vtkOpaquePass.h"
  8. include "vtkPieceScalars.h"
  9. include "vtkPolyDataMapper.h"
  10. include "vtkPSphereSource.h"
  11. include "vtkRenderer.h"
  12. include "vtkRenderPassCollection.h"
  13. include "vtkRenderWindow.h"
  14. include "vtkRenderWindowInteractor.h"
  15. include "vtkSequencePass.h"
  16. include "vtkSmartPointer.h"
  17. include "vtkSynchronizedRenderers.h"
  18. include "vtkSynchronizedRenderWindows.h"

int main(int argc, char**argv) {

 //---------------------------------------------------------------------------
 // Initialize MPI.
 vtkMPIController* controller = vtkMPIController::New();
 controller->Initialize(&argc, &argv);
 vtkMultiProcessController::SetGlobalController(controller);
 // Get information about the group of processes involved.
 int my_id = controller->GetLocalProcessId();
 int num_procs = controller->GetNumberOfProcesses();
 //---------------------------------------------------------------------------
 // Create Visualization Pipeline.
 // This code is common to all processes.
 vtkSmartPointer<vtkPSphereSource> sphere = vtkSmartPointer<vtkPSphereSource>::New();
 sphere->SetThetaResolution(50);
 sphere->SetPhiResolution(50);
 // Gives separate colors for each process. Just makes it easier to see how the
 // data is distributed among processes.
 vtkSmartPointer<vtkPieceScalars> piecescalars =
   vtkSmartPointer<vtkPieceScalars>::New();
 piecescalars->SetInputConnection(sphere->GetOutputPort());
 piecescalars->SetScalarModeToCellData();
 vtkSmartPointer<vtkPolyDataMapper> mapper = vtkSmartPointer<vtkPolyDataMapper>::New();
 mapper->SetInputConnection(piecescalars->GetOutputPort());
 mapper->SetScalarModeToUseCellFieldData();
 mapper->SelectColorArray("Piece");
 mapper->SetScalarRange(0, num_procs-1);
 // This sets up the piece-request. This tells vtkPSphereSource to only
 // generate part of the data on this processes.
 mapper->SetPiece(my_id);
 mapper->SetNumberOfPieces(num_procs);
 vtkSmartPointer<vtkActor> actor = vtkSmartPointer<vtkActor>::New();
 actor->SetMapper(mapper);
 vtkSmartPointer<vtkRenderer> renderer = vtkSmartPointer<vtkRenderer>::New();
 renderer->AddActor(actor);
 vtkSmartPointer<vtkRenderWindow> renWin = vtkSmartPointer<vtkRenderWindow>::New();
 renWin->AddRenderer(renderer);
 //---------------------------------------------------------------------------
 // Setup the render passes. This is just a very small subset of necessary
 // render passes needed to render a opaque sphere.
 vtkSmartPointer<vtkCameraPass> cameraP = vtkSmartPointer<vtkCameraPass>::New();
 vtkSmartPointer<vtkSequencePass> seq = vtkSmartPointer<vtkSequencePass>::New();
 vtkSmartPointer<vtkOpaquePass> opaque = vtkSmartPointer<vtkOpaquePass>::New();
 vtkSmartPointer<vtkLightsPass> lights = vtkSmartPointer<vtkLightsPass>::New();
 vtkSmartPointer<vtkRenderPassCollection> passes =
   vtkSmartPointer<vtkRenderPassCollection>::New();
 passes->AddItem(lights);
 passes->AddItem(opaque);
 seq->SetPasses(passes);
 // Each processes only has part of the data, so each process will render only
 // part of the data. To ensure that root node gets a composited result (or in
 // case of tile-display mode all nodes show part of tile), we use
 // vtkIceTCompositePass.
 vtkSmartPointer<vtkIceTCompositePass> iceTPass =
   vtkSmartPointer<vtkIceTCompositePass>::New();
 iceTPass->SetController(controller);
 // this is the pass IceT is going to use to render the geometry.
 iceTPass->SetRenderPass(seq);
 // insert the iceT pass into the pipeline.
 cameraP->SetDelegatePass(iceTPass);
 renderer->SetPass(cameraP);
 //---------------------------------------------------------------------------
 // In parallel configurations, typically one node acts as the driver i.e. the
 // node where the user interacts with the window e.g. mouse interactions,
 // resizing windows etc. Typically that's the root-node.
 // To ensure that the window parameters get propagated to all processes from
 // the root node, we use the vtkSynchronizedRenderWindows.
 vtkSmartPointer<vtkSynchronizedRenderWindows> syncWindows =
   vtkSmartPointer<vtkSynchronizedRenderWindows>::New();
 syncWindows->SetRenderWindow(renWin);
 syncWindows->SetParallelController(controller);
 // Since there could be multiple render windows that could be synced
 // separately, to identify the windows uniquely among all processes, we need
 // to give each vtkSynchronizedRenderWindows a unique id that's consistent
 // across all the processes.
 syncWindows->SetIdentifier(231);
 // Now we need to ensure that the render is synchronized as well. This is
 // essential to ensure all processes have the same camera orientation etc.
 // This is done using the vtkSynchronizedRenderers class.
 vtkSmartPointer<vtkSynchronizedRenderers> syncRenderers =
   vtkSmartPointer<vtkSynchronizedRenderers>::New();
 syncRenderers->SetRenderer(renderer);
 syncRenderers->SetParallelController(controller);
 //---------------------------------------------------------------------------
 // Now start the event loop on the root node, on the satellites, we start the
 // vtkMultiProcessController::ProcessRMIs() so those processes start listening
 // to commands from the root-node.
 if (my_id==0)
   {
   vtkSmartPointer<vtkRenderWindowInteractor> iren =
     vtkSmartPointer<vtkRenderWindowInteractor>::New();
   iren->SetRenderWindow(renWin);
   iren->Start();
   controller->TriggerBreakRMIs();
   controller->Barrier();
   }
 else
   {
   controller->ProcessRMIs();
   controller->Barrier();
   }
 controller->Finalize();
 vtkMultiProcessController::SetGlobalController(NULL);
 controller->Delete();
 return 0;

} </source>

vtkIceTCompositePass

The above example illustrates how to use vtkIceTCompositePass. vtkIceCompositePass a vtkRenderPass subclass that uses IceT for compositing. When instantiated across different processes, it ensures that a composite result is available in the active render buffer on the root node (or the tile-result on all node in tile-display mode). If not in tile-display mode, then the active buffer on that node ends up with the result of the rendering of the data available on that processes, which may be partial depending on your pipeline.

vtkIceCompositePass has API to indicate if we are to treat the setup as a tile-display i.e. treating all nodes as if they form a large display and then only show the tile from this large display that corresponds to this process.

If data is replicated on all nodes, you may consider setting vtkIceCompositePass::DataReplicatedOnAllProcesses to true, which avoids unnecessary compositing.

Whenever translucent geometry or volume rendering is involved, one needs to ensure that a KdTree which can be used to generate an order for ordered-compositing is provided. This may require that you redistribute that data so that a KdTree can be generated. You may want to look at vtkDistributedDataFilter for redistributing data.

vtkIceCompositePass works on active frame buffer, just like any other vtkRenderPass. Hence, if you want apply additional passes such as say Sobel edge detection or Gaussian blur, you can add the vtkIceCompositePass as the delegate pass for vtkSobelGradientMagnitudePass or vtkGaussianBlurPass. Of course, except in tile-display mode, all nodes execept the root will we processing partial results (if data is distributed).