User:Jsmeredith

Jeremy Meredith, Oak Ridge National Laboratory

Jeremy's rather ambitious thoughts on VisIt 2.0, or maybe 3.0.....

  • Component APIs
    • Make viewerproxy API not GUI-centric
    • Make CLI not so GUI-centric (as it's based on the viewer proxy interface), and possibly even object-oriented
    • Create an Engine which is directly linkable and usable by codes to do plotting and data analysis of in-data memory
  • Expressions/Operators/Queries
    • Merge them, at least to an appropriate degree, e.g. "c = isosurf(d, (min(p)+max(p))/2"
    • Create *new* meshes in expressions
    • Allow creation of new sources without having to save to a file (see ddf, query results, lineouts)
    • Major clean up and expansion of expression language, e.g. comparators could be symbols
    • Clean up expression infrastructure (expressions take a lot of work to code in visit)
    • DeferExpression feels like a hack, and queries can only be executed at fixed points in the pipeline
    • queries must operate on plots, even when you want to examine a database variable, and require that "primary variable" thing
    • pick -- with an extra rendering pass (or two, etc), we could support 100% accurate, instantaneous pick, for any type of plot with opaque geometry; just render the cell IDs into the frame buffer
  • Plugins
    • New types of plugins
      • Expressions
      • Queries
      • Even more, e.g. tools? interactors? renderers?
    • Clean-up
      • Do we need so many files with such a deep hierarchy for each plugin? Many plugins could have been a simple collection of a half-dozen flat functions.
      • Get rid of "GetVectorVar". Add "GetMaterial". And so on.
      • DB Plugins do a reasonable job determining if a given file is one of theirs
  • Attributes
    • Fully inspectable attributes could be used to create widget windows without needing to write or compile/link Qt code, and a Python interface without generating python code, and Java, etc
    • Dynamically definable attributes could be used to obviate hacks like DBOptions, avtDataSetAttributes manual writing, allow integration of attribute fields directly into keyframe editor (cf. 3DSMAX)
    • (I do have some code that shows this off a little)
  • Build Process
    • Fix Windows and OSX. cmake or whatever.
    • Support static executables building (if this is still important)
  • Plots
    • Animation within plots: requires plots to not be deleted when a new frame is generated
    • level-of-detail, even fully dynamic LOD
    • intermediate results (progressive updates)
    • multiple viewports in a window, e.g. simultaneous top/left/front views
    • multiple windows pointing to the same scene
    • plots should be created from database-forward, i.e. database, then operators, then the rendering
    • allow multiple "primary variables" (or, even better, none!). E.g. multivariate volume plot; contour plot using one variable for isosurf and a second for color; neither of these are "primary" or "secondary" varables
    • "small multiples"
  • Rendering
    • Directly support GLSL, or something. we technically do already, but something to abstract this and make it really acceptable would be a big help
    • Materials (textures, bump or image maps)
    • no custom renderers if at all possible; e.g. the molecule plot and surface plot simply shouldn't need them, and so many things have to be re-implemented, like specular options. label plot probably still needs one.
    • FOG! this is one example of our limitations of using VTK's rendering infrastructure, not sure what it's buying us
    • real-time shadows. Another example of something hard to work in to VTK.
    • OpenGL should just be one of many renderer options; why can't we have a "raytracing" renderer, or let users fall back to a "software renderer" if their OpenGL driver is borked?
      • As one example; the molecule plot should be very simple: map lines to cylinders with some coloring, map verts to spheres with some other coloring. This should be so simple and fast to raytrace, but we don't have any way of expressing this type of rendering at the right level to make it feasible.
  • Interaction/GUI
    • Abandon MeshTV interface
    • Open a "Group of files" instead of selecting them (is selecting files still useful?)
    • Adding operators with the ability to set their values before initially applying the operator -- (yes, we have a workaround, but it's a little confusing)
    • allow simultaneous editing of two pseudocolor plot settings or two transform operators within ones plot
    • MDI interface might be one possibility (or maybe even an option; you could certainly have the ability to dock/undock OpenGL windows in a Qt4 app to my knowledge)
    • More things like the spreadsheet plot; why not support a "Textual" output window modality, just like the 1D or 3D windows
    • tools support interactive updating, maybe on a lower LOD mesh
  • Data Model
    • Time handling; it's too much a special case. We should support *any* type of discrete dimensions, like vibration mode, "model" (PDB file), time, random independent variable index, or even partition of input data (see small multiples again)
    • Materials should be part of the actual data model. Probably impossible with VTK.
    • Must be able to have independent variables on various dimensionalities of data. VTK unfortunately lumps all cell types into one group, so if you have "fluxes" on a mesh surface, you either have to provide dummy values for the 3D cells or separate the 2D cells from the 3D cells as separate meshes (with separate 3D points, which is the reason that's a bad idea).