home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / sgi / graphics / 179 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  2.1 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!spool.mu.edu!sgiblab!sgigate!odin!fido!woof!airey
  2. From: airey@woof.asd.sgi.com (John Airey)
  3. Newsgroups: comp.sys.sgi.graphics
  4. Subject: Re: Severe speed hit when windows clip polygons
  5. Date: 21 Jan 1993 18:17:44 GMT
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. Lines: 32
  8. Message-ID: <1jmpc8INN7l1@fido.asd.sgi.com>
  9. References: <1993Jan20.190707.28040@aio.jsc.nasa.gov>
  10. NNTP-Posting-Host: woof.asd.sgi.com
  11.  
  12.  
  13. In article <1993Jan20.190707.28040@aio.jsc.nasa.gov>, mancus@carla.jsc.nasa.gov writes:
  14. > 
  15. >   We are presently attempted to develop a real-time application
  16. > that must run at a 30 Hz graphical update rate.  We are finding
  17. > that a serious slowdown occurs when the displayed models are too
  18. > large to fit in the display window.  As soon as ANY clipping occurs,
  19. > we lose as much as 10 Hz!  (Test case: 3000 polygon flat-shaded
  20. > sphere, no tmeshes, monocolored, 340VGX, no accumulation buffer,
  21. > window is 1024x768.  The final product will run on a RealityEngine,
  22. > CPU unspecified.)
  23. >   What can we do to avoid this speed hit?  Our simulation will
  24. > have to show polygons that are cut by the window borders, but
  25. > we just can't live with this kind of penalty.  Are there GL
  26. > calls we are omitting?
  27. > 
  28. > -- 
  29. > | Keith Mancus    <mancus@cheers.jsc.nasa.gov>                           |
  30. > |                 N5WVR                                                  |
  31. > | "Money is never *mere*.  It separates the feasible                     |
  32. > |    from the infeasible."                                               |
  33.  
  34.    Clipping does require work. It can slow you down. However, the Reality
  35. Engine was engineered to handle this problem. You should benchmark your
  36. app on a RealityEngine before you get too worried. Secondly, there is
  37. some work afoot which allows spheres to be drawn extremely quickly on
  38. a RealityEngine. You might try e-mailing srf@sgi.com with questions about
  39. spheres on RealityEngine.
  40.  
  41. john m. airey      airey@asd.sgi.com  (415) 390-5248
  42.                    M/S 7U-553 Silicon Graphics, Advanced Graphics Division
  43.                    2011 N. Shoreline Blvd., Mtn. View, CA 94039  
  44.