[vtk-developers] ARB - feature addition

[Dean Inglis]

Hi Will,

I'll wait until things calm down a bit on the dashboard, perhaps
later this week.

>I didn't quite understand what you were proposing in the sense of having a
>class in between vtk3DWidget and these new classes. I'm wondering instead
>how about a vtkImageWidget or vtk2DWidget abstract superclass. Could you
>explain what these new widgets have in common and what features they need
>from vtk3DWidget?

There are a few common features:
1) 2D glyph handles (or possibly user defined)
2) handle geometry enforced to be on a particular image axis aligned plane:
  this is the same API as in vtkImagePlaneWidget, vtkSplineWidget
3) vtkImageTracerWidget, vtkImageSplineWidget and vtkImageROIWidget
  all make use of vtkImageData as the underlying vtkDataSet from the
  vtk3DWidget API: SetInput(vtkDataSet*)

these widgets are 3D and not really 2D as in the sense of vtkActor2D,
although something like a transfer function widget I would think should
be truly 2D, much like vtkScalarBarWidget.

>+ You are using vtkGlyph2D to generate the glyphs. Why not generalize the
>class further and allow the user to set any polydata? By default you could
>depend on Glyph2D but still open it up for other choices.

The original motivation to develop these "image" widgets was to circumvent
using 3D spherical handles and have 2D planar handles (for 2D plane images),
so vtkGlyph2D was my first choice.  With the advent of ITK, I will be
steering
away from VTK/Imaging and writing my own VTK image processing filters and
integrating
ITK with VTK in my apps: VTK for visualization and a series of image
processing
widgets for interactivity etc.

I'm not sure on how to enable permitting any polydata for the handles:
perhaps
such widgets might maintain a polydata to copy from???

<in .h definition>
  public:
     void SetHandleGeometry(vtkPolyData*);
  protected:
     vtkPolyData* BaseHandle;
     void GenerateHandles();
  vtkActor          **Handle;
  vtkPolyDataMapper **HandleMapper;
  vtkPolyData       **HandleGeometry;
<snip>

<in .cxx implementation>

void vtkSomeWidget::SetHandleGeometry(vtkPolyDate* poly){
   this->BaseHandle->CopyStructure(poly);
}

void vtkSomeWidget::GenerateHandles(int nhandles){
  this->InitializeHandles();  //clear them out
  this->NumberOfHandles =  nhandles;
  for(int i = 0;i<this->NumberOfHandles;i++)
   {
    this->HandleGeometry[i] = vtkPolyData::New();
    this->HandleGeometry[i]->CopyStructure(this->BaseHandle);
<snip>

Currently with vtkGlyph2D, the polydata it produces has to be
transformed since the glyph is by default generated centered on
the origin (0,0,0) in the x-y plane.  So far, this hasn't been a
problem, although every time a handle is moved, its position is
defined as follows (e.g., from vtkImageTracerWidget):

void vtkImageTracerWidget::AdjustHandlePosition(int handle, double pos[3])
{
  if(handle < 0 || handle >= this->NumberOfHandles){ return; }

  if (this->ProjectToPlane)
    {
    pos[  this->ProjectionNormal ] = this->ProjectionPosition;
    }

  this->HandleGeometryGenerator->SetCenter(0.0,0.0,0.0);
  this->Transform->Identity();
  this->Transform->PostMultiply();
  this->Transform->RotateZ(this->GlyphAngle);

  if(this->ProjectionNormal == VTK_ITW_PROJECTION_YZ)
    {
    this->Transform->RotateY(90.0);
    }
  else if(this->ProjectionNormal == VTK_ITW_PROJECTION_XZ)
    {
    this->Transform->RotateX(90.0);
    }

  this->Transform->Translate(pos);
  this->TransformFilter->Update();


this->HandleGeometry[handle]->CopyStructure(this->TransformFilter->GetOutput
());
  this->HandleGeometry[handle]->Modified();
}

>A couple quick notes on your API for the ImageTraceWidget:
>+ GetPolyData returns the path. Why not GetPath ?

The path is a polydata and I was just following the convention
currently used on the other widgets, but GetPath sounds fine to me.

thanks for the feedback so far...
Dean