The Visualizaton Cascade

1. The Visualizaton Cascade Beyond the Visualization Pipeline Werner Benger1, Marcel Ritter, Georg Ritter, Wolfram Schoor 1Scientific Visualization Group Center for Computation & Technology at Louisiana State University

2. Outline • The Concept and Limitations of the Viz Pipeline • Generalization of the Visualization Cascade • Implementation Concepts within VISH

3. The Visualization Pipeline • A concept of how visualization works Haber & McNabb, 1990 Data Flow: Data Source  Data Filter  Data Sink

4. Implementations via Unix Pipelines • Example: ppmplustoolkit cat image.jpg | jpegtopnm | pnmscale -w 100 | cjpeg -quality 40 | display • Data flows from source to display • Each step is parametrized • More complex application leads to graphs • Many sources (input data) • Filters may be interconnected • Usually one sink (display)

5. Visualization Networks • Represents data flow • Allows visual programming (AVS, Amira, OpenDX, Iris Explorer, Vish) Data Data Parameter Filter Filter Renderer File Storage

6. Push Model • Data at the source is pushed downstream through filters to the data sink File reading, network transfer, computation, … Action Result Image Rendering

7. Push Model (downstream) • AVS, Amira, … Data Data Parameter Filter Filter Renderer File Storage

8. Pull Model • Date sink requests run upstream through filters requesting data from the source source File reading, network transfer, computation, … Source Request Image Rendering

9. Pull Model (upstream) • OpenDX, VTK, Vish, … Data Data Parameter Filter Filter Renderer File Storage

10. Push vs. Pull Push model Pull model • Data are made available as soon as possible • Traverses viz pipeline after loading/creation • Filter modules have information about data available at early stage • Loads data even if not used • Data are made available as late as possible • Traverses viz pipeline at rendering time • Filter modules don’t know all about data until output is requested • Loads only data when used

11. Dynamic Large Data • Pull model is convenient during interaction since all data information is available during setup of viz pipeline parameters • Easier in implementation since no upstream information flow (triggers) • Problematic for time-dependent large data which don’t fit into memory, because cannot load all data • Repeated operation and caching?

12. Dynamic Data Traversing Time: Viz Pipeline needs to be traversed for each time step: T=0.0 T=0.4 T=0.8 T=1.2 Data Data Data Data Filter Filter Filter Filter Renderer Renderer Renderer Renderer

13. Dynamic Data & Push Model New time – new data – new traversal – entire pipeline re-computed T=0.0, 0.4, 0.8, 1.2 Data Data Data Data Filter Filter Filter Filter Renderer Renderer Renderer Renderer

14. Dynamic Data & Pull Model New time – skip traversal if results already are available (result caching) Data Data Data Data Filter Filter Filter Filter Renderer Renderer Renderer Renderer T=0.0, 0.4, 0.8, 1.2

15. Visualization Cascade Make the Viz Pipeline aware of Caching Data Data Data Data Filter Filter Filter Filter Renderer Renderer Renderer Renderer T=0.0, 0.4, 0.8, 1.2

16. Caching on each Level Enable Partial traversal of viz pipeline Data Data Data Filter Filter Filter Renderer Renderer Renderer

17. Caching on each Level Enable Partial traversal of viz pipeline Data Data Data Filter Filter Filter Renderer Renderer Renderer

18. Cacheable/Non-Cacheable Parameters Which parameters full re-traversal of the vizpipeline? Data Data Data Filter Filter Filter Parameter Renderer Renderer Renderer

19. Cacheable/Non-Cacheable Parameters • Example: Isosurface of dynamic data Isosurface Time Load new data from disk Data Data Data Isosurface Level Recompute Isosurface But don’t load new data Filter Filter Filter Isosurface Color Redraw Surface But don’t recompute Renderer Renderer Renderer

20. New Time or New Data? • Time parameter could also be trigger parameter for new data computation • When to cache data? Will old cache data ever be reused? • Concept: Cache at data source location, not at node location.

21. Result Cacheing Result caching at pipeline node possible, but not problematic, because parameter space is unknown T=0.0, 0.4, 0.8 Data Data Data Filter Isosurface T=0.0 Isosurface T=0.4 Isosurface T=0.8 Renderer

22. Operator Caching • Cache data at location of data source • If data source vanishes, so vanishes cached results • Filter objects do not store any data, but are purely procedural T=0.0, 0.4, 0.8 Data Data Data Isosurface T=0.0 Isosurface T=0.4 Isosurface T=0.8 Filter Renderer

23. Fiber Bundle Data Model • Is a generic approach to handle a wide range of data types used for scientific visualization • Basic concept: Base space maps to fibers Fiber Space at each point of Base Space Base Space

24. Central Data Management • Covers scalar,vector,tensor fields on unispatial grids, mesh refinement, multiblocks, particle systems, surfaces, … • “garbage collection” management with I/O layers for sciviz data

25. Viz Pipeline on the Fiber Bundle • All data are stored in the “Bundle” • Viz nodes • do not store any data • pass references to data • purely procedural Fiber Bundle Data Filter Renderer

26. Operations on the Fiber Bundle Data filtering is actually mapping objects within the fiber bundle Fiber Bundle Filter

27. Time Support in Fiber Bundle Fiber Bundle • Bundle is a hierarchical system of slices • Intrinsic support for time in the Bundle • Time as a visualization parameter • Data “flow” is reduced to bundle access parameters T=0.8 T=0.0 T=0.4 Data Filter Renderer

28. Time Support in Fiber Bundle Fiber Bundle • If time slice of source data is gone, then also all cached data is gone • Cache as much results as there are source data T=0.8 T=0.0 T=0.4 Data Filter Renderer

29. Hierarchy of the Fiber Bundle • Consists of 6 hierarchy levels Field Representation Topological Skeleton Grid object (Time) Slice Bundle Field Cartesian Coordinates Vertices Grid T=0.0 Fiber Bundle

30. Access via Parameters Field Fieldname Cartesian Coordinates Vertices Coordinate system Topological Property Grid T=0.0 Gridname Fiber Bundle Time

31. Coding Example (Operations) BundleB; double time; Slice S = B[ time ]; string Fieldname; Grid G = S[ Fieldname ]; // Computation of an Isosurface: // Provide 3D data volume (uniform coordinates) // Name of a field given on this volume // A floating point value specifying the isosurface level GridCompute( Grid DataVolume, string Fieldname, double Isolevel);

32. Coding Example GridVizNode::compute(Bundle&B, doubletime, stringGridname, stringFieldname, doubleIsolevel) { // Construct a unique name for the computational result stringIsosurfaceName = Gridname + Fieldname + Isolevel; // Check whether result already exists for the given time GridIsoSurface = B[ time ][ IsosurfaceName ]; if (!IsoSurface) { // No, thus need to retrieve the data volume GridDataVolume = B[ time ][ Gridname ]; // and perform the actual computation IsoSurface = Compute( DataVolume, Fieldname, Isolevel); // finally store the resulting data in the bundle object B[ time ][ IsosurfaceName ] = IsoSurface; } return IsoSurface; }

33. GPU Cascade Cache Final Data at the GPU - OpenGL:vertex buffer objects, display lists, textures) Data Data Data Data Filter Filter Filter Filter Renderer Renderer Renderer Renderer T=0.0, 0.4, 0.8, 1.2

34. GPU Cascade RAM  GPU Memory Data Data Data Data Filter Filter Filter Filter Renderer Renderer Renderer Renderer T=0.0, 0.4, 0.8, 1.2

35. GPU Memory not part of Bundle Fiber Bundle GPU requires own Cache T=0.8 T=0.0 T=0.4 Data Filter Renderer

36. OpenGL Cache mirrors Sources Fiber Bundle Fiber Bundle T=0.8 T=0.8 T=0.0 T=0.0 T=0.4 T=0.4 Data Filter Renderer

37. Associate OpenGL ID’s with Sources Fiber Bundle Fiber Bundle T=0.8 T=0.8 T=0.0 T=0.0 T=0.4 T=0.4 Data Filter Renderer

38. Replay from OpenGL ID’s Fiber Bundle Fiber Bundle T=0.8 T=0.8 T=0.0 T=0.0 T=0.4 T=0.4 Data T= 0.8 T=0.4 T=0.0 Filter Renderer

39. The GL Cache • “Lives” within an OpenGL Context • Provides 3-dimensional indexing scheme to yield OpenGL ID’s: • Reference to data source (e.g. Fiber Bundle object) • Viz Node type information • Set of viz node parameters • Some parameters might require re-generation of OpenGL objects, others may allow reusage • Creates one ID per input set GLuintDisplayList = GLCache[ void* ] [ typeinfo] [ set<void*> ]; Iso Surface Render Para-meters T=0.4

40. Coding Example voidVizNode::render(GLCache Context, Grid G) { ValueSet VS; // assign cacheable variables into the value set … GLuintDisplayList = GLCache[ &G ] [ typeid(this) ] [ VS ]; if (!DisplayList) { DisplayList= glGenLists(1); glNewList(DisplayList, COMPILE_AND_EXEC); // do actual rendering of grid data G … glEndList(); GLCache[ Intercube ] [ typeid(this) ] [ VS ] = DisplayList; } else glCallList(DisplayList); }

41. Demo!

42. Availability • Code development management: • http://sciviz.cct.lsu.edu/projects/vish • Available via SVN in source code for registered users at http://vish.origo.ethz.ch/