News | People | Our Github

VCB - A Visualization Component Library

 

1. Download

Please click on DOWNLOAD to get the current code as well as binary (version 1.1) in a tarball. The code is under LGPL license. To view the full list of "cooking" ingredients as well as the documentation, please click here. For "cooking" directions, please go here. For example recipes, please look at the main programs under the libtestsrc directory in the tarball of the full source.

2. Synopsis

Visualization CookBook library (vcblib) is a collection of common basic visualization functions, packaged into a form where individual functions are kept as orthogonal to each other as possible. VCB serves both as a foundational layer in real-world visualization applications as well as in benchmarking applications to motivate high-impact computer systems research such as high-performance networking and storage.

3. Current Status

Right now, for the following common visualization tasks, the ingredients have been developed and well tested:

1. Volume rendering using ray-casting

2. Sparse volume rendering using splatting

3. 3D isosurface extraction

4. Line integral convolution (LIC) of a 3D flow field

5. Flow advection in 3D and 4D flow fields and obtain

5.1 a set of streamlines (rendered with/without shading)

5.2 a particle system

Current users include ourselves and our colleagues in areas including grid computing, distributed computing, high-speed networking, computer architecture and GPGPU. After making a full public release in May 2007, we have had more than 100 downloads of the source and more than 40 downloads of the binary.

To report bugs or if you have some general comments, please email vr_dev AT cs dot utk dot edu.

A long bit of -- Why we did this to begin with

Over the years, the visualization community has produced on a number of successful visualization toolkits. However, it has not been very easy for computer science researchers in systems oriented areas to adopt many of the existing visualization codes in basic systems research projects. This seems in part due to the steep learning curves of visualization techniques and also the restrictions that are introduced by the complexity of these toolkits when it becomes necessary to port to a novel platform, sometimes one that is even pre-beta stage.

At Seelab, University of Tennessee, with our collaborators within the department as well as at ORNL, we undertook a different approach of packaging the existing viz codes for ease of use, mostly motivated by the following observation. While much of the complexity in visualization application software resides in how complex input data are managed and how user interaction are handled, the core part of the visualization algorithms, such as volume rendering and line integral convolution, does not vary that much from one application to another.

Due to this observation, we set off to implement a library of visualization functions that strictly focus on visualization operations. This library does not deal with user interface at all. Nor does it deal with complex file formats. The only requirement for this library is that to invoke any function of this viz module, one should only need to make a (or a few) simple C function call, no different from calling "printf". Besides the simplicity in the API, we also require that to invoke a function, for instance to extract an isosurface, the application programmer should only need to read the corresponding documentation for that function; just like when an undergrad learns to output a line on his console, he only needs to read the reference page of "printf" and nothing more. In addition, the visualization library should be sufficiently self-dependent such that other dependent libraries or softwares needed by a user are minimal. The same library should run on Linux, Unix, Windows and Macintosh machines from exactly the same code base. Not even using #define for platform dependencies.

After working on this library, especially during the process to develop and document the testing programs, we stumbled onto a very interesting analogy that has to do with cooking. When we cook, there is a finite set of common ingredients to use. Each ingredient normally has a few different ways of use. At the same time, there are recipes that talk about how ingredients should be combined together to make a great dish. To our great luck, there are practically unlimited number of interesting dishes for us to try in a life time. In terms of doing visualization, our library seems to be starter set of ingredients. We document each function API and tell people how the ingredients should be used, that is the directions. At the same time, the developers, particularly those that write parallel and distributed applications, can either use a known recipe or possibly come up with their own recipes.