home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / graphics / opengl / 224 next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.7 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!sgi!fido!cashew.asd.sgi.com!kurt
  2. From: kurt@cashew.asd.sgi.com (Kurt Akeley)
  3. Newsgroups: comp.graphics.opengl
  4. Subject: Re: OpenGL and GL tmesh
  5. Date: 21 Dec 1992 17:43:47 GMT
  6. Organization: Silicon Graphics, Inc.
  7. Lines: 46
  8. Distribution: inet
  9. Message-ID: <1h4vojINN9s5@fido.asd.sgi.com>
  10. References: <APM.92Dec19175627@kikka.hut.fi>
  11. NNTP-Posting-Host: cashew.asd.sgi.com
  12.  
  13. -- 
  14.  
  15. In article <APM.92Dec19175627@kikka.hut.fi>, apm@kikka.hut.fi (Antti Miettinen) writes:
  16. |> I can't find any mention about a counterpart for GL swaptmesh() in the
  17. |> OpenGL manual pages that I got from sgi.com. Does this mean that
  18. |> swaptmesh() is going away and I should avoid it? It seems that you can
  19. |> draw triangle strips and fans but no longer combinations.
  20. |> 
  21. |> Please say it's not true.
  22.  
  23. Sorry, it's true.
  24.  
  25. |> Fiddling with trimeshes has been so much
  26. |> fun. I mean.. the intellectual challenge of drawing some geometry as
  27. |> one single trimesh and figuring out the correct swaps and.. But
  28. |> seriously - wouldn't it be pretty easy to provide the counterpart
  29. |> provided that an OpenGL implementation has to offer strips and fans?
  30.  
  31. Not necessarily.  Our experience with implementing swaptmesh() on our
  32. own machines is that it is easy and straighforward on pipeline machines,
  33. (such as the GT for which it was designed) but difficult and complex on
  34. the more parallel machines that we have designed more recently (VGX,
  35. Elan, RealityEngine).
  36.  
  37. |> And it would save sending a couple of vertices here and there.
  38. |> Propably typically not a great saving but if it is easy to provide and
  39. |> increases compatibility then wouldn't it be a good idea to include it?
  40.  
  41. We agree that the savings aren't very great.  We decided, when we were
  42. designing the OpenGL, that the savings in vertexes wouldn't be worth the
  43. cost in both implementation complexity and the likely overall reduction
  44. in implementation performance.
  45.  
  46. |> First I thought that glEdgeFlag() could be used for the purpose but
  47. |> the manual page states that it is significant only if polygon mode is
  48. |> point or line. Hmm.. is the following a contradiction? First the man
  49. |> page states that "In particular, glEdgeFlag may be called between a
  50. |> call to glBegin and the corresponding call to glEnd" and in the ERRORS
  51. |> section "GL_INVALID_OPERATION is generated if glEdgeFlag is called
  52. |> between a call to glBegin and the corresponding call to glEnd".
  53.  
  54. Yup, and a blatant one at that!  The NOTE is correct, the ERRORS entry
  55. is wrong.  EdgeFlag would be useless if it could not be called between
  56. Begin and End.  Thanks for calling this to our attention.
  57.  
  58. -- Kurt Akeley        kurt@sgi.com  (415) 390-3612  M/S 7U-550
  59.