THE VISUALIZATON CASCADE

Beyond the Visualization Pipeline Werner Benger1, Marcel Ritter, Georg Ritter, Wolfram

Schoor1Scientific Visualization Group

Center for Computation & Technologyat

Louisiana State University

Outline

The Concept and Limitations of the Viz

Pipeline

Generalization of the Visualization Cascade

Implementation Concepts within VISH

The Visualization Pipeline

A concept of how visualization works

Haber & McNabb, 1990

Data Flow:Data Source Data Filter Data Sink

Implementations via Unix Pipelines

Example: ppmplus toolkit

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)

Visualization Networks

Represents data flow Allows visual programming (AVS, Amira,

OpenDX, Iris Explorer, Vish)

Data Data Parameter

Filter Filter

Renderer File Storage

Push Model

Data at the source is pushed downstream through filters to the data sink

Action

Result

File reading, network transfer, computation, …

Image Rendering

Push Model (downstream)

AVS, Amira, …

Data Data Parameter

Filter Filter

Renderer File Storage

Pull Model

Date sink requests run upstream through filters requesting data from the source source

Source

Request

File reading, network transfer, computation, …

Image Rendering

Pull Model (upstream)

OpenDX, VTK, Vish, …

Data Data Parameter

Filter Filter

Renderer File Storage

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

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?

Dynamic Data

Traversing Time: Viz Pipeline needs to be traversed for each time step:

Data

T=0.0

Filter

Renderer

Data

T=0.4

Filter

Renderer

Data

T=0.8

Filter

Renderer

Data

T=1.2

Filter

Renderer

Dynamic Data & Push Model

New time – new data – new traversal – entire pipeline re-computed

Data

T=0.0, 0.4, 0.8, 1.2

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

New time – skip traversal if results already are available (result caching)

Dynamic Data & Pull Model

Data

T=0.0, 0.4, 0.8, 1.2

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

Make the Viz Pipeline aware of Caching

Visualization Cascade

Data

T=0.0, 0.4, 0.8, 1.2

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

Caching on each Level

Enable Partial traversal of viz pipeline

Data

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

Caching on each Level

Enable Partial traversal of viz pipeline

Data

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

Cacheable/Non-Cacheable Parameters

Which parameters full re-traversal of the viz pipeline?

Data

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

Parameter

Cacheable/Non-Cacheable Parameters

Example: Isosurface of dynamic data

Data

Filter

Renderer

Data

Filter

Renderer

Data

Filter

RendererIsosurface Color

Redraw SurfaceBut don’t recompute

Isosurface LevelRecompute Isosurface

But don’t load new data

Isosurface TimeLoad new data from

disk

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.

Result Cacheing

Result caching at pipeline node possible, but not problematic, because parameter space is unknown

Data Data

Filter

Renderer

Data

T=0.0, 0.4, 0.8

Isosurface T=0.0 Isosurface

T=0.4 Isosurface T=0.8

Isosurface T=0.8

Isosurface T=0.4

Isosurface T=0.0

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

Data Data

Filter

Renderer

Data

T=0.0, 0.4, 0.8

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

Base Space

Fiber Space at each

point of Base Space

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

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

Data

Filter

Renderer

Fiber Bundle

Operations on the Fiber Bundle

Data filtering is actually mapping objects within the fiber bundle

Filter

Fiber Bundle

Fiber BundleT=0.0

Time Support in 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

Data

Filter

Renderer

T=0.4 T=0.8

Fiber BundleT=0.0

Time Support in 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

Data

Filter

Renderer

T=0.4 T=0.8

Fiber Bundle

Hierarchy of the Fiber Bundle

Consists of 6 hierarchy levels

T=0.0

Grid

Vertices

CartesianCoordinates

Field1. Field

2. Representation

3. Topological Skeleton

4. Grid object

5. (Time) Slice

6. Bundle

Fiber Bundle

Access via Parameters

T=0.0

Grid

Vertices

CartesianCoordinates

Field

Time

Gridname

Topological Property

Coordinate system

Fieldname

Coding Example (Operations)

Bundle B;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 levelGrid Compute( Grid DataVolume, string Fieldname, double Isolevel);

Coding Example

Grid VizNode::compute(Bundle&B, double time, string Gridname, string Fieldname, double Isolevel)

{// Construct a unique name for the computational result

string IsosurfaceName = Gridname + Fieldname + Isolevel;// Check whether result already exists for the given time

Grid IsoSurface = B[ time ][ IsosurfaceName ];if (!IsoSurface){

// No, thus need to retrieve the data volumeGrid DataVolume = B[ time ][ Gridname ];

// and perform the actual computationIsoSurface = Compute( DataVolume, Fieldname, Isolevel);// finally store the resulting data in the bundle objectB[ time ][ IsosurfaceName ] = IsoSurface;

}return IsoSurface;

}

Cache Final Data at the GPU - OpenGL:vertex buffer objects, display lists, textures)

GPU Cascade

Data

T=0.0, 0.4, 0.8, 1.2

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

RAM GPU Memory

GPU Cascade

Data

T=0.0, 0.4, 0.8, 1.2

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

Data

Filter

Renderer

Fiber BundleT=0.0

GPU Memory not part of Bundle

GPU requires own Cache

Data

Filter

Renderer

T=0.4 T=0.8

OpenGL Cache mirrors Sources

Data

Filter

Fiber BundleT=0.0 T=0.4 T=0.8

RendererFiber BundleT=0.0 T=0.4 T=0.8

Associate OpenGL ID’s with Sources

Data

Filter

Fiber BundleT=0.0 T=0.4 T=0.8

RendererFiber BundleT=0.0 T=0.4 T=0.8

Replay from OpenGL ID’s

Data

Filter

Fiber BundleT=0.0 T=0.4 T=0.8

RendererFiber BundleT=0.0 T=0.4 T=0.8

T=0.0

T=0.4

T= 0.8

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

GLuint DisplayList = GLCache[ void* ] [ typeinfo ] [ set<void*> ];T=0.4

IsoSurface

RenderPara-

meters

Coding Example

void VizNode::render(GLCache Context, Grid G){ValueSet VS;

// assign cacheable variables into the value set…

GLuint DisplayList = 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);}

Demo!

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/