Re: Memory problems with VisAD

• To: Charles Beyer <cjbeyer@xxxxxx>
• Subject: Re: Memory problems with VisAD
• From: Bill Hibbard <hibbard@xxxxxxxxxxxxxxxxx>
• Date: Tue, 19 Feb 2002 09:11:50 -0600

Hi Charles,

> Have you looked at all into using OpenGL directly via gl4java?  I've heard
> many people complain about java3d not being useful precisely because of it's
> scene graph nature.  In data visualization one often wants to just push data
> to the graphics cards as fast as possible, not create an intermediate scene
> graph, since the data sets are way too large.

VisAD is designed to support new graphics APIs. The classes
in visad.java3d and visad.java2d extend classes and interfaces
in the core visad package, and it would certainly be possible
to define another set of extension classes for gl4java in a
visad.gl4java package. Note that visad.java3d contains about
9500 lines of code, and visad.java2d contains about 6500 lines
of code, just to get an idea of the scale of the effort.

Transforming data into geometry is generally quite a bit
slower than rendering that geometry (since custom hardware
exists for rendering geometry but not for creating geometry),
so visualization systems generally have some way to save
geometry. For example, Vis5D uses OpenGL but saves geometry
internally. However, it detects when its using up memory and
discards geometry, marking it for recomputation. And if the
data set is really large, it always recomputes geometry. An
application could define extensions of the visad.java3d
classes to behave in these ways, possibly using Java3D's
immediate mode rendering, or possibly saving a scene graph
for only the currently rendered geometry.

Cheers,
Bill
----------------------------------------------------------
Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI  53706
hibbard@xxxxxxxxxxxxxxxxx  608-263-4427  fax: 608-263-6738
http://www.ssec.wisc.edu/~billh/vis.html

• References:
  • RE: Memory problems with VisAD
    • From: Charles Beyer