User:Dcthomp

Just this guy, you know.

Various Viz Invectives

Easy-to-use selections and "element cursor"

• Keyboard navigation of a mesh with a "cursor", a la Mucke and Edelsbrunner. It is a really elegant way to select a single node, edge, face, or cell. The cursor is always located at a node of the mesh and it points from that node along some edge of the mesh. The user then presses keys to move the cursor or enters the ID of a new point or cell to "warp" to another part of the mesh:

  < - opposite face on next element
  > - opposite face on previous element
  e - next (co)edge on current face of current element
  f - next face on current (co)edge of current element
  r - opposite coedge of current edge (i.e., switch to neighboring element sharing same edge on current face loop).

I've used this for debugging mesh connectivity problems and it works quite well.

• Mouse navigation, a la Solidworks/ProE. Although it's intended for single (not multiple) selections, the nice thing about SolidWorks and ProE is that you can select surfaces that are partially or totally obscured using multiple mouse clicks:

  left click - draw a line through current pixel, selecting topmost element

then

  right click - move down (further from image plane) along selection line
  middle click- move up (towards image plane) along selection line
  left click - complete selection

• Also a la Solidworks: toggle buttons to filter selection by type (ele/face/edge/node, perhaps inc/excl specific datasets).

• Again, selections are first class objects! There should be an icon (or stack of icons for each refinement of a selection?) for current selection that you drag/drop. If selection is a single node/face/edge you should be able to drop it onto plane normal of a filter to set the plane base point, normal, etc. Perhaps a couple of way to do it to indicate whether updating the selection should update the plane as well?

This would be a way to tie filter inputs together so that the same plane gets used in several places, the same isovalue gets applied to several datasets, etc.

Collaboration

It would be interesting to add an "out-of-band" protocol to Jabber spec for collaboration + some XML elements to the "in-band" chat notes that refer to datasets, elements, selections, screen coordinates, etc. . Out-of-band communications could be any combination of:

• client-server command streams
• datasets (geometry for client to render when compositing disabled)
• image data (images for client to render when compositing enabled)

The Jabber protocol presents some interesting use cases for collaboration:

• single pvserver with multiple users
  • one user has "the conch"; all users see exactly the same thing (images or geom+view from pvserver sent to all users)
  • all users have their own pipelines based on same source data and can send their pipelines to other users
  • users may have privelege to see newly derived data generated by others?
  • all users share pipline but viewpoints can vary; users can send views plus annotations to others
• one pvserver per user: users send entire piplines; both clients and servers communicate to make this happen.
• Jabber allows public forums and private, invite-only rooms for secure collaborations.

Queries

• Apple Automator-style filters for datasets. An example:
  • elements whose nodal "Temp" values exceed 320 C
  • AND/OR/XOR elements whose nodal vector velocity (magnitude/component [XYZ]) is between 0 and 10
  • ...
• The queries would all be of the form:

 (node|element|face|edge) (of (edge|face|element)s (id-list)?)? (whose (nodal|cell|edge|face|...) field (X|Y|Z|magnitude)?
   (is|is between|is not|is not between|contains|matches) value1 (and value2)?

• For info-vis where there's lots of free-form data a Beagle(Linux)- or Spotlight(Apple)-style search bar might make sense. Even for scientific vis, it might makes sense to search for dataset filenames and their fields.

Scripting

Although I've heard hints that Python scripting will be available in ParaQ, it's not noticable in beta. Easy-to-use syntax really important. Current TCL scripting in ParaView is not easy to use. Current things like setting the camera eye/aim require

         [[$Application GetMainWindow] GetMainView] SetViewingParameters eyex eyey eyez aimx aimy aimz upx upy upz

it should be like this:

         client.setActiveView('Main 3D')
         camera.setEye( [x,y,z] )
         camera.rotateAbout( [x,y,z], phi )

By having some predefined variables (app, view, camera) that are kept up to date (so that effectively there is a state machine), it is simple to use when there is a single view without having to learn a lot about the application's hierarchical structure. Having to say app.view['Main 3D'].camera['Perspective'].setEye( [x,y,z] ) is tedious and unneccesary. However, the dictionary syntax should be present as well.

It's also important to have help and/or completion available within the scripting language. For instance:

       help(client)

should yield some information like:

 "The client application contains global settings such as a working directory URL, plus dictionaries of
 the application windows, viewports, cameras, animations, dialogs, filter graphs, selections, etc. A full
 list is below. ..."

It should be really easy to write/modify queries (such as those in the section above) in the scripting language:

       filt = pvQueryFilter()
       filt.setInput( server.datasets['HighTempElements'] )
       clause1 = pvQueryFilterClause( 'elements whose nodal vorticity > 10' )
       clause2 = pvQueryFilterClause( 'elements whose cell temperature is in [320,1000[' )
       filt.setQuery( pvQueryFilterClause( clause1, AND, clause2 ) )

Animations

Channels and timeline like Final Cut Studio/other nonlinear editors. ParaView had the beginnings of this. You should be able to drag and drop datasets/views(camera)/filters/properties/Python variables into a timeline channel. Selecting a camera channel in the animation will display an editable TNB-spline in all "geometric" viewports.

Provenance/Pedigree and Annotations

A system not unlike Claudio Silva's notebook system should be used to archive all interaction and uniquely mark it. Perhaps subversion/WebDAV could be used to save session history. Images and animations should store the pipeline that created them (or references to the session history at a minimum). This would be a great use of PNG comment fields. That way, one could load a PNG image of a dataset and have the server recreate the session that created the picture.

If subversion/webdav were used for storing session traces, the history could be retrieved from an online repository no matter what machine created it. Also, having a URL for a session would allow users to write annotations for datasets in their favorite word processor and refer directly to the session from their annotations. Along with PNG files containing references, it provides an easy way to use existing content management systems to save a wide variety of documentation that is closely tied to the ParaQ session.