[Paraview-developers] ParaView Usability Improvements

Fri Mar 5 18:29:21 EST 2010

I'm clearly adding to this conversation late because I was on travel yesterday.  I was going to comment that we should change some filters to handle more types of data.  We had talked long ago about automatically running cell to point for filters that only accept point data.  I'm no longer convinced that is a great idea as that filter implicitly mangles the data.  For example, what does it mean to contour cell data?  To me, it seems the right thing to me is to extract all faces that have neighbors with cell values on the opposite sides of the contour (or at least that is the best you can do without mangling the data).

Here is some other oddness I have noticed or has been brought up on the mailing list:

 *   There are separate gradient filters for image and unstructured data.  It would be straightforward to write a metafilter that picks the correct gradient implementation given the input.
 *   The transform filter only works on point data sets.  Users have wanted to use it on image data.  It would be easy and not to memory consumptive to have the transform filter convert images and rectilinear grids to structured grids.  Likewise for warp by scalar or vector.
 *   There are two "clean" filters, and the names don't make sense.  I can't believe more people haven't complained about it.  I figure they must be too confused to ask.  At the very least the names should be more representative of what they do: "Clean Poly Data" and "Clean to Unstructured Grid".  It might be nice if they were somehow rolled into one (poly data input would stay poly data input, all others converted to unstructured grids).  However, that might be confusing behavior.
 *   I've seen users get confused that the "Generate Surface Normals" filter only works on poly data.  This is especially confusing because unstructured grids often look like poly data and poly data is sometimes converted to unstructured grids without the user knowing (for example, if running the clip filter).  Perhaps this filter could be changed to work on unstructured grids as well (ignoring non 2D cells).  Or perhaps it could implicitly extract the external surface.
 *   Speaking of the external surface, the filter name "Extract Surface" is stupid.  Extract what surface?  A contour is a surface.  A plane is a surface.  The filter should be named "Extract External Surface" or simply "External Surface".
 *   At some point, the statistics functionality needs to be reworked (sorry, Dave).  They are hard to use even if you know what you are doing, and few people do.

-Ken

On 3/4/10 8:19 AM, "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com> wrote:

Autoconverting to some extent is reasonable and already planned eg.
converting point data to cell data etc., but converting image data to
unstructured grid (or such) can be risky due the memory bloat. Maybe
when a filter is disabled, showing why it is disabled in the status
bar (or something) may not be a bad idea.

Utkarsh

On Thu, Mar 4, 2010 at 10:15 AM, Jeff Baumes <jeff.baumes at kitware.com> wrote:
> Along with Dave's comment, I think auto-converting would be good to
> help with this. For example, if you want to warp an image, can't you
> just implicitly convert it to geometry? The result is that many things
> would not be greyed out anymore.
>
> It seems that would help with the cognitive load, so people don't even
> need to know what all the different vtkDataObject subclasses are and
> how to convert between them manually.
>
> That said, making icons for the different data types in the pipeline
> browser would probably help too, instead of everything just being a
> green cube.
>
> Jeff
>
> On Thu, Mar 4, 2010 at 9:41 AM, David E DeMarle
> <dave.demarle at kitware.com> wrote:
>> One thing that new users don't like is that it is hard to find out
>> what filters do really and more frustratingly, why they are greyed out
>> once you know what one you want.
>>
>> We should do a better job of documenting the input and output types of
>> each reader/source/filter/writer, what specifically it does, and what
>> the input restrictions (domains) are. Perhaps we can automate the
>> collection of that from the class hierarchy, doxygen, and the xml and
>> expose it in some intuitive manner in the UI. For example using icons
>> to represent input data set types and presence of cell/point scalars
>> etc.
>>
>> I will try to put up some mockup on the wiki page shortly.
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 28 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-371-3971 x109
>>
>>
>>
>> On Sat, Feb 27, 2010 at 11:45 AM, Moreland, Kenneth <kmorel at sandia.gov> wrote:
>>> There is lots of good stuff here.  I added a bunch of megalomaniacal
>>> comments.
>>>
>>> -Ken
>>>
>>>
>>> On 2/26/10 10:27 AM, "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com> wrote:
>>>
>>> Folks,
>>>
>>> Following a discussion with Berk, I've started consolidating the ideas
>>> for the improvements on a Wiki page.
>>> Please start contributing your suggestions.
>>>
>>> http://www.paraview.org/ParaView3/index.php/ParaView_Usability_Improvements
>>>
>>> Utkarsh
>>> _______________________________________________
>>> Paraview-developers mailing list
>>> Paraview-developers at paraview.org
>>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>>
>>>
>>>
>>>
>>>    ****      Kenneth Moreland
>>>     ***      Sandia National Laboratories
>>> ***********
>>> *** *** ***  email: kmorel at sandia.gov
>>> **  ***  **  phone: (505) 844-8919
>>>     ***      web:   http://www.cs.unm.edu/~kmorel
>>>
>>>
>>> _______________________________________________
>>> Paraview-developers mailing list
>>> Paraview-developers at paraview.org
>>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>>
>>>
>> _______________________________________________
>> Paraview-developers mailing list
>> Paraview-developers at paraview.org
>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>
>
>
>
> --
> Jeff Baumes, Ph.D.
> R&D Engineer, Kitware Inc.
> (518) 881-4932
> jeff.baumes at kitware.com
> _______________________________________________
> Paraview-developers mailing list
> Paraview-developers at paraview.org
> http://public.kitware.com/mailman/listinfo/paraview-developers
>

   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20100305/f6902b21/attachment.htm>