Introduction to Viz Cookbook
1. Motivation
Over the years, the visualization community has made significant progress on a number of subjects, manifested by the availability of multiple visualization toolkits in the field. However, it has not been very easy for researchers and application developers to adopt many of the existing codes on various research projects, partly due to a quite steep learning curves and also the restrictions that are introduced by the complexity of these toolkits when porting to a novel platform is necessary.
At Seelab, University of Tennessee, with our collaborators at ORNL, for the benefit of our and our collaborators' daily research, we undertook a different approach of packaging the existing viz codes for ease of use, mostly motivated by the following observation.
No matter how complicated a visualization software would have to be to meet its user needs, most of the complexity resides in how user interaction should be handled. Fortunately, this part is quite easy to implement, considering the fact that most first graduate students can do a decent job after taking one semester's graphics class. At the same time, the core of the whole software, the part that requires advanced knowledge of visualization algorithms such as volume rendering and line integral convolution, does not vary that much from one application to another. Unfortunately, this part is not what many graduate students can correctly implement and achieve high performance.
Due to this observation, we set off to implement a library of visualization functions that strictly focus on advanced 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 without modifications to the code base.
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 are only a quite limited number of common ingredients to use. Each ingredient normally has a few directions of how it should be used. 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 good 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 application developers, that is the people who work closely with scientists and solve real problems, should be the ones that come up with the recipes. With this in mind, our goal is now quite a bit grandier than what we originally set out with. We now want to produce all ingredients that would fulfill our needs and our friends' needs, but also we want to collect recipes and eventually publish a somewhat powerful and interesting Cookbook for Visualization.
2. Current Status
Right now, for the following common visualization tasks, the ingredients have been developed and alpha-tested:
1. to volume render a solid volume using ray-casting
2. to volume render a sparse volume using splatting
3. to extract an isosurface from a 3D volume
4. to compute a line integral convolution (LIC) of a 3D flow field
5. to compute flow advection in 3D and 4D flow fields and obtain
5.1 a set of streamlines (to be rendered with or without shading)
5.2 a particle system
A few recipes have been produced to visualize isosurface, flow field and volume rendered volumes. Most existing recipe example programs use GUI's written with GLUT, a gui toolkit that has been ported to Linux, Mac and Windows.
The ingredients library is a C library that takes less than 2MB storage. It has been shown in our daily work that the library performs equally well in sequential programs and parallel programs using libraries like MPI, etc.
The directions and recipes documentation for the Viz Cookbook have not currently been completed.
3. A Few Short Examples
3.1 To compute a LIC volume of a flow field
float * flowvol;
unsigned char * licvol;
/* the test flow field is 48x48x48 */
flowvol = (float *) malloc (48*48*48*3*sizeof(float));
fread(flowvol, sizeof(float), 48*48*48*3, fp);
licvol = (unsigned char *) malloc(48*48*48);
vr_genlictex3d(flowvol, licvol, 48, 48, 48);
......
3.2 To extract an isosurface
unsigned char * vol;
float isoval = 30.f;
float * vdata;
int * fdata;
int nfacets;
int sz[3];
/* assuming a test dataset of 64x64x64 */
vol = (float *) malloc (64*64*64*sizeof(unsigned char);
sz[0] = sz[1] = sz[2] = 64;
nfacets = vr_mcblock(VR_UNSIGNEDBYTE, vol, isoval, sz, ONLYVERTEX, &nverts, &vdata, &fdata));
/*
* now, nfacets triangles have been extracted. the output
* triangle mesh has nverts vertices. the coordinate of
* each vertex is stored in the linear array vdata and
* the vertex list of each triangle is stored in
* the array of fdata
*/
.........