[vtk-developers] [InfoVis] Propsosed new vtkPainter that enables/disables data using scalars

[Moreland, Kenneth]

I'm not thrilled with this solution.  It seems a bit "hacky".

The underlying problem here is that vtkScalarsToColors basically defines a
1D transfer function (1 scalar -> 1 color), and what you really want is a 2D
or higher transfer function (X scalars -> 1 color).

Thus, I would recommend changing the interface of vtkScalarsToColors to
accept vector values for GetColor and GetOpacity.  The current subclasses
can basically stay the same by ignoring all vector components but the first.
You could then make new subclasses that provide multidimensional transfer
functions like the one you describe below.

-Ken


On 9/21/08 7:00 PM, "Stanton, Eric T" <etstant at sandia.gov> wrote:

> There is a need to be able to control the color saturatation, value, and alpha
> of a vtkPolyData using a different set of scalars than the ones used to color
> by. The use case is to be able to "enable" and "disable" edges and vertices of
> a graph using edge and vertex attributes that take on values of either 0 or 1.
> In this example, edges with scalar values of 1 would be fully saturated and
> opaque while those with a value of 0 would be grayed out and translucent. The
> "enabled" portion of the graph could then still be colored by a different
> attribute.
>
> I've written a new painter to support this behavior (not committed yet)
> currently called vtkScalarsToHighlightPainter. It is similar to
> vtkScalarsToColorsPainter except that it overrides the saturation, value, and
> alpha of its input scalars (leaving the hue alone) using the mapped scalars
> from its own lookup table. I considered incorporating this functionality in to
> the existing vtkScalarsToColorsPainter but found that it would significantly
> complicate its api and implementation.
>
> The question should be asked, though, why stop there? Why not be able to
> control hue, saturation, value, and alpha separately using (possibly)
> different lookup tables and scalars for each? That's perfectly valid. The
> result would be to break up vtkScalarsToColorsPainter into
> vtkScalarsToHuePainter, vtkScalarsToSaturationPainter, etc. The
> "enable/disable" behavior described above could still be produced in this
> case.
>
> The major concern I have is how many VTK classes adding this new painter would
> affect. It would need to be added to vtkDefaultPainter's pipeline of painters.
> vtkPainterPolyDataMapper::UpdatePainterInformation() would need to be able to
> set painter-specific information properties. And vtkMapper would need new API
> for configuring the array to "highlight" by similar to its existing API for
> setting the array to color by.
>
> Is this the right approach in order to get the enabled/disabled effect I want?
> If so, is there someone at Kitware who I could get guidance from with regard
> to its integration in to VTK?
>
> Thanks,
>
> Eric Stanton
> Scalable Analytics and Visualization
> Sandia National Labs
>
>


   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      fax:   (505) 845-0833