home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / graphics / explorer / 463 next >
Encoding:
Text File  |  1993-01-21  |  3.9 KB  |  88 lines

  1. Newsgroups: comp.graphics.explorer
  2. Path: sparky!uunet!gatech!cc.gatech.edu!cc.gatech.edu!zundel
  3. From: zundel@cc.gatech.edu (Eric Zundel Ayers)
  4. Subject: Renderer Performance, Interactivity
  5. Message-ID: <1993Jan21.052834.29868@cc.gatech.edu>
  6. Keywords: Renderer, geometry, Glyphmaker
  7. Sender: news@cc.gatech.edu
  8. Reply-To: zundel@cc.gatech.edu (Eric Zundel Ayers)
  9. Organization: Georgia Institute of Technology
  10. Date: Thu, 21 Jan 1993 05:28:34 GMT
  11. Lines: 75
  12.  
  13. We are doing research to create an interactive scientific visualization 
  14. tool (the Glyphmaker) using Explorer.  Our goal is to allow the scientist
  15. to define graphic primitives and bind them to the scientist's
  16. specific set of data.  
  17.  
  18. Our goal is for the scientist to get quick feedback as he experiments with 
  19. different bindings between data and graphic primitives.  We have
  20. been using  Explorer's Renderer module to render our images to
  21. leave the system open for expansion.  Unfortunately, we have run into 
  22. performance problems:
  23.  
  24. (our tests were run on an Iris Indigo Elan)
  25.  
  26. 1) In a scene with  160 spheres, rendering takes from 3 - 9 seconds,
  27.    and rotations in the renderer take between 5 and 10 seconds. 
  28.    This is on the edge of what we have defined as "interactability"
  29.  
  30. 2) In a scene with 1200 spheres (which is not uncommon in the kind of 
  31.    data we are working with right now) Times increase to well over a
  32.    minute to render but still around 10 seconds to rotate.  
  33.  
  34.    The "lengthy" rendering time is certainly acceptable for a final image, 
  35.    but we'd like for the user to get a quick sketch of what the scene might
  36.    look like in a short amount of time (a few seconds) so that he/she can 
  37.    experiment with different parameters and run many test runs.  
  38.  
  39.    Unfortunately, we don't get much savings in the initial rendering time 
  40.    (when the geometry structure is sent from our module to the renderer)
  41.    by changing the drawstyle, or by changing the complexity (tesselation) 
  42.    of the spheres we draw.  Although we now have some faster hardware 
  43.    (a Reality Engine)  there must be some changes that can be made in 
  44.    software to increase interactivity.
  45.  
  46.    Also, there is no feedback from the renderer in the act of making
  47.    a rotation, which makes it very difficult to tell how far the scene
  48.    has been rotated.
  49.  
  50.  
  51. 3) In a scene with 2500 spheres, the renderer has lots of problems,
  52.    with rendering time increasing exponentially for each attempt to
  53.    render the same scene.(first 2 minutes, then 4 minutes, then 8 minutes...) 
  54.  
  55.    Is this problem described a bug in the software or is it a problem
  56.    with the settings on our machines? Will we be able to view scenes with 
  57.    2000+ spheres in the 2.0 Renderer? 
  58.    
  59.   
  60. Could there be some inefficiency in the way we are creating the
  61. Geometry data structure?  What could we do to change that?  
  62.  
  63. Is it possible that the renderer module for Explorer 2.0 will be 
  64. substantially quicker than the current version?   Is it possible that there is a quicker renderer with less features
  65. available (or could one be made available?)
  66.  
  67. Finally, we are looking for a way to get information from the
  68. Renderer by Picking a region in the renderer.  The pick-box is nice,
  69. but we'd like to get information about the original geometry from the
  70. renderer, such as  "spheres 34, 35, and 36 are in the selection set"
  71. and then, say,  perform an operation that makes those spheres transparent.
  72. Since our data does not begin as a 3-D lattice, the data we get out
  73. is not very helpful (as far as I can tell) with the kinds of manipulations 
  74. to the data we'd like to do.
  75.  
  76. We are considering writing our own rendering code, but then we
  77. have lost almost all of the advantages of using Explorer.  If possible,
  78. we would like to stick with the built in modules.  
  79.  
  80.  
  81. Any and all feedback gratefully appreciated!
  82.  
  83. Eric.
  84. Eric Z. Ayers
  85. zundel@cc.gatech.edu
  86. Graphics, Visualization, and Usability Center (GVU)
  87. Georgia Institute of Technology, Atlanta, GA 30213 USA 
  88.