From: andyrose@netcom.com (San Francisco Fractal Factory)
Subject: Re: Databases for Visualization data?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Mon, 5 Oct 1992 18:42:22 GMT


realliso@unity.ncsu.edu (Robert Allison) writes:
> a study on the use of databases (or DBMSs) for the storing
> and retrieval of data used in visualization.
> 
> It looks like most of the Visualization software works with 
> the data in RAM, and then can save images into files, but 
> not many seem to use any 'database' concepts to store and
> retrieve the data.
> 
> Thanks,
> Robert Allison (realliso@unity.ncsu.edu)
>

Database issues are the heart of visualization (arguably)
and I think there are some softwares which use 'database'
concepts.

In the simple case, examine a Wavefront PreView file
to see a TABLE.  Column headings are Transformation and
display parameters for 'objects' {lights, cameras, things-
to-look-at, dummys} and data exists for each time-step
(typically 30 time steps a second for video).   Associated
with each object (which may have a number of channels)
is some data about type, filename, and editable or not.
  object#/channel#  1/1  1/2  1/3  1/4  2/1  2/2  etc.
   heading        xrot   yrot  zrot d   xrot  yrot  
time step      --------------------------------------
1               45.00 ,etc.
2
3

Database concepts used for dealing with this table are 
display column heads, display a column, display object
info, build and edit a 'selected object' list, on which
other actions act, etc.

It doesn't make much sense to sort this table accept by
time step, although some 'block moves' and 'time stretching'
is neccessary.  

On output, some database concepts, like compression are
(could be) used for space considerations.  

Next up is GEOMETRIC DATA.  Often libraries of 3D shapes
are created for a job.  If several people are working on
the job it is nice to manage the sharing of the data,
especially if multiple users are accessing the same object.
This is implemented with Unix using symbolic links or copies.
Not very sophisticated.  Representing 3D shapes in memory
is certainly a data structure issue.

If the displayable data is being generated for each
time step, perhaps in real-time, database concepts, like the
server-client relationship, can be used.

Also in the database concept domain is MATERIAL DATA.  This
describes physical attributes of an object, like color,
reflectivity, and highlight size, as well as texture mapping
data.  This is a DATABASE in terms of having records like
material name, ambient color, diffuse color, etc.

In Wavefrontland, the material editor acts as a graphic
editor of the material library.

The above pertain to animation lists and 'renderable' 
properties, which is not all of scientific visualization.

I think the distributed model which AVS is based on 
illuminates some database concepts.  This is a 'visual
programming language' where the user selects 'modules'
or functional units and connects them graphically.

These units can be selected from 'libraries' or 
'toolboxes' which are physically disparate.  The
execution of the functions can also be assigned
to processors removed from each other.  This leaves
a lot of room for clever database code to serve
the processors.  Sometimes data can be shared
(if net speeds are high), sometimes data must
be COPIED (instanced).  

 
> not many seem to use any 'database' concepts to store and
> retrieve the data.

What concepts?

-- 
Andrew Rose andyrose@netcom.com FAX 4155537756 When peace rules the planet