4.2 Advantage of the Model
In our proposing model, geophysical fluid scientists
can observe the results of 3D visualization via a web
browser without installing any visualization packages
and with the benefit of high-end 3D visualization re-
sources. Live streaming by Flash animation is OS-
independent. Although the installation of a plug-
in is required for watching the Flash animation, the
Flash player is a popular plug-in and easy for users
to install. Actually, most web browser users have in-
stalled the Flash player plug-in because Flash media
is widely common. The benefit of streaming media
is that clients need not download the movie data into
their hard disks. It saves client users from considering
about the storage capacity to watch as long movies as
they want.
In our model, the process of 3D visualization,
movie generation of visualization results, and live
streaming distribution is performed on a visualization
server. In this process, it is unavoidable that dropping
frames sometimes occur because of regular sampling
of snap shot images. During scientific data analysis
with 3D visualization, the essential requirement is to
guarantee that scientists surely recognize the display
changes caused by their operations. In our model, a
display of a 3D visualization result does not change
unless a new command is issued. Therefore, drop-
ping frames are not a critical problem for our model
unlike stream distribution of animation which always
changes their display.
4.3 Implementation
4.3.1 Interactive 3D Visualization for Remote
Data
The 3D visualization functions executed in visualiza-
tion servers include volume rendering and 3D con-
tour plot by GPGPU with Cg as a shader language.
The Cg language can be used from OpenGL APIs.
For volume rendering and 3D contour plot, we use
VTK, which supports OpenGL as low level APIs. We
develop the 3D visualization functions in Cg so that
they are callable from any VTK program
2
as well as
Gfdnavi. Taking the advantage of collaboration with
GPGPU, the 3D visualization functions of the visual-
ization server will achieve high performance visual-
ization.
We here explain the performance issue. Namely,
how fast GPGPU based 3D visualization is? As
2
We know VTK5.2 will officially support Cg and GLSL,
but we don’t like to wait for the future release.
for volume rendering by GPGPU, it has been re-
ported that the frame rate of displaying 166MB vol-
ume data consisting of a (512,512,333) array on an
Nvidia Quadro FX 3400 GPU is 15.3fps(F. Schulze
and Hadwiger, 2007). In the case of 3D contour plot,
it has been reported that the frame rate of displaying
588MB volume data consisting of a (700,700,600) ar-
ray on an ATI Radeon X800 with 256 MB memory
is 28.7fps(B. von Rymon-Lipinski and Keeve, 2005).
Although the frame rates change by the complexity of
the volume data, considering the reported GPUs are
relatively old, the real-time 3D visualization (30fps)
is almost possible on the latest high-end GPUs as de-
scribed in the next subsection.
In our model, the visualization server receives op-
eration commands from client users, and the 3D vi-
sualization functions are invoked by the commands.
Receiving commands, if necessary, the visualization
server needs to get target data from a DB server (may
be equivalent to a Gfdnavi server). The data dealt with
geophysical fluid research mainly consists of four di-
mension arrays, and is so large in size. Downloading
the whole data in advance of 3D visualization to the
visualization server, the waiting time may sometimes
irritate client users. To solve the problem, we use the
Gphys library of Gfdnavi, which clips the three di-
mension domain specified by users. Clipping just the
necessary data, the data size is reduced to shorten the
data transfer time.
In our implementation, we adopt a double trans-
fer scheme assuming that the network bandwidth be-
tween the visualization server and the Gfdnavi server
is enough high such as two nodes in a PC cluster with
a high speed interconnection network. According to
a data transfer request, when the target data is larger
than the pre-defined size, Gphys is invoked to clip and
performs partial data transfer. At the same time, the
whole data is transferred to the visualization server
in background. This background data transfer is ex-
pected to complete until the client user makes another
clip request after several visualization operations. If
so, the new clip is obtained in local, i.e. from the
pre-loaded whole data in the visualization server. If
not so, the requested clip is transferred from the Gfd-
navi server again keeping the background whole data
transfer. In this way, we ensure the interactive opera-
tion for web based client users keeping from the huge
data transfer overhead.
4.3.2 Live Streaming
3D visualization results are taken as snap shot images
with 320× 240 at every
1
30
seconds. An mpeg ani-
mation is generated from those images at every sec-
GRAPP 2008 - International Conference on Computer Graphics Theory and Applications
412