Visualization Pipeline Display
From K-3D
Overview
Here we're collecting everything on the design and development of components for displaying the Visualization Pipeline. We know that there are going to be UI components that can't be handled with straight GTK widgets, and the pipeline is probably the most obvious example (timelines and channel editors also come to mind).
Try using the GraphVizEngine in a non-trivial document to get a feel for just how complicated the graph will get. For those unfamiliar, the GraphVizEngine is a render engine that "renders" documents using GraphViz, which is a popular automated graph-layout tool.
Requirements
It's critical that any serious attempt at a visualization pipeline display have a clean separation between filtering and layout policies. See k3d/ngui/node_list.h for some preliminary work that was done in this area. Note that designs should not assume that one node in the display corresponds to a single node in the document, nor should it assume that all nodes and all connections are visible at any given time. Providing subsetting and display functionality to limit the display in useful ways will be essential to manage complexity for users.
Compact Display
 A compact display of nodes as symbols with connections. |
 Compact display with 3D shadow effects. |
 Compact display approaching the limits of legibility. |
 Micro display with hollow connection symbols. |
Expanded Display
 Fully expanded display with detailed property and connection info. |
 Fully expanded display with nested MetaNodes. |
Visual Node Connection Editing (ViNCE)
 |
 |
 |
 |
 |
 |
Implementations
There are many possible ways to implement a graphically-complex widget, each with their own pros and cons:
Amanith
http://www.amanith.org/blog/index.php
Cairo
GDK
GnomeCanvas
OpenGL
http://www.opengl.org - OpenGL
OpenGL with Hyperbolic Geometry
http://www.caida.org/tools/visualization/walrus
PCB Design and automatic track routing
- Connection Routing , the Rat's nest problem.
We haven't done due diligence on any of these approaches, so it's impossible to rule anything out at this time.
Visual Program Editor or Interface
- http://www.opendx.org
- http://www.research.ibm.com/dx/docs/legacyhtml/pages/usrgu037.htm#FIGUSE2
- http://flowdesigner.sourceforge.net
- http://www.nongnu.org/om-synth/flowcanvas.html
- Dia, with python scripting
- The pydiadoc.py script will display class diagrams, this could apply to K-3D documents?
- springgraph
- converts a .dot from graphviz to other formats including a true 3D VRML scene
- NetworkX (NX) is a Python package for the creation, manipulation, and study of the structure, dynamics, and functions of complex networks.
- VisTrails is a new system that enables interactive multiple-view visualizations by simplifying the creation and maintenance of visualization pipelines, and by optimizing their execution. It provides a general infrastructure that can be combined with existing visualization systems and libraries.
- Finite State Machine Editor, http://fsme.sourceforge.net/ has a graph-editing UI.
Visual Programming Interface(VPI) offers better understanding then present Node List Interface. The idea is to replace or offer an alternative to the present Node List Interface Panel.
The VPI would provide visualization of the flow between the nodes has provided by the GraphViz output. The Object Properties Panel become also an alternative, as the properties can be accessed by double clicking a node.
Providing switching between those two representations is an undecided functionalities.
Functionality such has undo is a must.
The VPI provides hierarchical building. It is like building your own modules. You are creating a sub node for the top node. It could provides modularization of the nodes.
