home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / graphics / explorer / 205 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  1.5 KB
  1. Path: sparky!uunet!wupost!uwm.edu!rutgers!sgigate!odin!fido!hashimoto
  2. From: hashimoto@sgi.com (Roy Hashimoto)
  3. Newsgroups: comp.graphics.explorer
  4. Subject: Re: IsosurfaceLat2 normals
  5. Message-ID: <pnin6rg@fido.asd.sgi.com>
  6. Date: 11 Sep 92 16:54:36 GMT
  7. References: <1992Sep10.220413.11698@ncar.ucar.edu>
  8. Sender: news@fido.asd.sgi.com (Usenet News Admin)
  9. Distribution: na
  10. Organization: Silicon Graphics, Inc.
  11. Lines: 28
  12.  
  13. In article <1992Sep10.220413.11698@ncar.ucar.edu> scheitln@ncar.ucar.edu (Tim Scheitlin) writes:
  14. >I have a question about the Explorer IsosufaceLat2 module.
  15. >Some of the polygons in the isosurfaces I am generating with this module 
  16. >appear to have their normals pointing in the wrong direction.
  17.  
  18. That's rather peculiar, all the normals should be right or all should be
  19. wrong.  What kind of graphics do you have, do you see the same behavior
  20. on the original IsosurfaceLat, and is your input lattice curvilinear?
  21.  
  22. >My question is:  Is the problem I am having with incorrect normals 
  23. >related to the bug in the original Marching Cubes algorithm?
  24.  
  25. No, that bug just causes polygons to be missing.  Normal generation is
  26. entirely separate.
  27.  
  28. Here are my guesses:
  29.  
  30. 1.  You have a curvilinear lattice that reflects on itself so that cells
  31. can have two different "senses".
  32.  
  33. 2.  The module has a bug in normal generation.  Quite possible, but it's
  34. strange that we haven't seen it before.
  35.  
  36. 3.  There is a bug in the rendering code or the GL.  Very unlikely, but
  37. not out of the question.
  38.  
  39. Roy Hashimoto
  40. hashimoto@sgi.com
  41.