🚀 go-pugleaf

We are doing research to create an interactive scientific visualization 
tool (the Glyphmaker) using Explorer.  Our goal is to allow the scientist
to define graphic primitives and bind them to the scientist's
specific set of data.  

Our goal is for the scientist to get quick feedback as he experiments with 
different bindings between data and graphic primitives.  We have
been using  Explorer's Renderer module to render our images to
leave the system open for expansion.  Unfortunately, we have run into 
performance problems:

(our tests were run on an Iris Indigo Elan)

1) In a scene with  160 spheres, rendering takes from 3 - 9 seconds,
   and rotations in the renderer take between 5 and 10 seconds. 
   This is on the edge of what we have defined as "interactability"

2) In a scene with 1200 spheres (which is not uncommon in the kind of 
   data we are working with right now) Times increase to well over a
   minute to render but still around 10 seconds to rotate.  

   The "lengthy" rendering time is certainly acceptable for a final image, 
   but we'd like for the user to get a quick sketch of what the scene might
   look like in a short amount of time (a few seconds) so that he/she can 
   experiment with different parameters and run many test runs.  

   Unfortunately, we don't get much savings in the initial rendering time 
   (when the geometry structure is sent from our module to the renderer)
   by changing the drawstyle, or by changing the complexity (tesselation) 
   of the spheres we draw.  Although we now have some faster hardware 
   (a Reality Engine)  there must be some changes that can be made in 
   software to increase interactivity.

   Also, there is no feedback from the renderer in the act of making
   a rotation, which makes it very difficult to tell how far the scene
   has been rotated.


3) In a scene with 2500 spheres, the renderer has lots of problems,
   with rendering time increasing exponentially for each attempt to
   render the same scene.(first 2 minutes, then 4 minutes, then 8 minutes...) 

   Is this problem described a bug in the software or is it a problem
   with the settings on our machines? Will we be able to view scenes with 
   2000+ spheres in the 2.0 Renderer? 
   
  
Could there be some inefficiency in the way we are creating the
Geometry data structure?  What could we do to change that?  

Is it possible that the renderer module for Explorer 2.0 will be 
substantially quicker than the current version?   Is it possible that there is a quicker renderer with less features
available (or could one be made available?)

Finally, we are looking for a way to get information from the
Renderer by Picking a region in the renderer.  The pick-box is nice,
but we'd like to get information about the original geometry from the
renderer, such as  "spheres 34, 35, and 36 are in the selection set"
and then, say,  perform an operation that makes those spheres transparent.
Since our data does not begin as a 3-D lattice, the data we get out
is not very helpful (as far as I can tell) with the kinds of manipulations 
to the data we'd like to do.

We are considering writing our own rendering code, but then we
have lost almost all of the advantages of using Explorer.  If possible,
we would like to stick with the built in modules.  


Any and all feedback gratefully appreciated!

Eric.
Eric Z. Ayers
zundel@cc.gatech.edu
Graphics, Visualization, and Usability Center (GVU)
Georgia Institute of Technology, Atlanta, GA 30213 USA