[vtkusers] "Disabling" a volume rendering pipeline in a controlled way?

[David Gobbi]

On Tue, Jun 28, 2016 at 12:04 PM, Elvis Stansvik <
elvis.stansvik at orexplore.com> wrote:
>
>
> So my question is: What is the proper way of "unhooking" (or "disabling"
> if you will) a pipeline? I want the render window to simply show empty
> space when in this state, but still have the entire pipeline intact and
> ready for when I next want to set the filename of the reader to a valid
> volume.
>

I've found it convenient to build the pipeline in segments, with shallow
copies as necessary to connect the segments.

For example, the reader is handled like this (drastically simplified code):

void ReadImage(vtkImageData *data, const char *filename)
{
  vtkSmartPointer<vtkImageReader2> reader =
vtkSmartPointer<vtkImageReader2>::New();
  reader->SetFileName(filename);
  reader->Update();

  vtkImageData *image = reader->GetOutput();

  // shallow copy the data into the supplied data object
  data->CopyStructure(image);
  data->GetPointData()->PassData(image->GetPointData());
}

My app has a data management structure (i.e. an object) that contains a
list of all the images that the app needs.  So to read a new file, I create
a new vtkImageData object, call the above function to populate it via the
reader, and then I connect it to the rest of my pipeline.  The reader
object is temporary.  By doing my code like this, it's easy to support a
broad range of readers.

Most processing pipelines are done the same way: they exist just long
enough to generate an output.  Afterwards, the filter objects are deleted
and only the output is kept (via a shallow copy done with the
CopyStructure()/PassData() calls above).

Display pipelines (e.g. pipelines that terminate with a mapper) have a
longer life: when I need to display a new data set, I generate the display
pipeline as well as its actors, then I connect an input and add the actors
to the renderer.  When I unload a data set, I also remove the actors. I
have a class for each display pipeline that I need, and objects of these
class are instantiated and destructed when data is loaded or unloaded.
Having as much of your program logic as possible tied to object
construction/destruction helps to simplify things.

Interactive processing pipelines (as opposed to the run-once pipelines) are
temporarily connected to a display pipeline via the usual
AddInputConnection() mechanism, but when the interaction is complete the
following is done: 1) the connection is broken with e.g.
RemoveAllInputConnections(), 2) the output is shallow-copied into a new
data object with the CopyStructure()/PassData() calls and the processing
pipeline is deleted, and 3) the copy is connected directly to the display
pipeline (and generally stored in my data management structure, as well).

The general idea is that pipeline segments only exist for as long as they
are being used, i.e. they are either limited to the scope of a single
function, or limited to the lifetime of a specific object. This helps to
reduce the overall resource usage of the application.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160628/35cf696c/attachment.html>