long message - double support, notifications, user feedback

John Biddiscombe j.biddiscombe at rl.ac.uk
Tue Apr 25 05:51:20 EDT 2000

My apologies for this lengthy message, please inform me if it should be
directed to the 

Part 1 double support
As Bill (L) - (and maybe some others) have noticed, I started adding some
VTK_DOUBLE support.
vtkAppendPolyData highlighted exactly the sort of problem I expected.
Sending N inputs to vtkAppendPolyData didn't work if they contained points
arrays which were VTK_DOUBLE, because it created an output vtkPoints object
which was VTK_FLOAT by default, copies from inPts to outPts failed after

Correcting the problem involved modifying a number of classes (thanks Bill)
and I expect that if I change any other filters a similar thing may happen.

My main concern is that many many filters create an output points array
which is VTK_FLOAT and so any data I send in gets irretrievably munged.
Really all filters which generate PointSet or derived classes should use the
same resolution for their outputs as for their inputs - unless there's a
good reason!. (ignoring multiple input filters for now!).

I'd like to add a function along the lines of
in vtkPolyDataSource (pointSetSource?)
which will examine the inputs and create a points array with the correct
type ready for the output.

However....this only half addresses the problem. All the filters have
float *myPtsData...etc etc etc
and use float all the time.

It's true that for visualization purposes float resolution is fine, but the
pipeline architecture is just too good to waste on visualization only.
Interfacing the visualization pipeline onto the "data pipeline" or the
"computation pipeline" is what most of us are doing (I expect), and there
are lots of useful filters which can be used for many applications.

I'm going to (slowly) start experimenting with a few filters and hopefully
find some elegant means of adding automatic preservation of datatype, If
anyone has suggestions or views, then I'll be glad to hear them.

Part 2 Notifications
In the past, I've wanted to add an event callback to the ReleaseData /
SetNthOutput mechanism to enable a GUI to catch changes in data type.

Since there's only myself wanting this, it doesn't seem fair to add it in.

The main objection to a callback of the type above is that it could lead to
a proliferation of

But...While pondering ways around this, I was thinking about the windows
which windows sends out to a parent, when child windows do things.

and on and on. But a possible way around this would be to have a single


and define messages along the lines of

etc etc (they're just made up examples). And provide a small buffer (void
pointer) for args/data etc etc (like wParam, lParam).

Each vtkObject would have a single event handler and it could be reused by
any process/filter to supply callback messages to the parent program.

A single vtkMessageDefinitions.h would contain valid IDs and optionally a
used to enable/disable them via
similar to debug messages being turned on and off.

good idea?


Part 3 user feedback
When writing embedded filters. by which I mean, filters whgich contain more
filters, I'm frustrated by the fact that I can't put additional information
inside the UpdateProgress(...) handlers to give
a) more detailed info, such as "starting BSP tree build", "Raytracing",
"Collecting results"
b) the ability to pass updates down or up the filter heirarchy so that
embedded filters can be "visible" inside their owners

I'd like to add functionality to ProcessObject to support this. If anyone
has comments....

John B

More information about the vtk-developers mailing list