home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / sgi / 16394 < prev    next >
Encoding:
Internet Message Format  |  1992-11-14  |  2.9 KB
  1. Path: sparky!uunet!ogicse!decwrl!concert!borg!pooh!cullip
  2. From: cullip@pooh.cs.unc.edu (Timothy Cullip)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Texture Lookup Table (tlutdef) on RealityEngine
  5. Message-ID: <17478@borg.cs.unc.edu>
  6. Date: 13 Nov 92 15:48:48 GMT
  7. Article-I.D.: borg.17478
  8. Sender: news@cs.unc.edu
  9. Distribution: usa
  10. Lines: 51
  11.  
  12. I've written a type of volume renderer for the RealityEngine that
  13. uses 3D texture. It is currently using a one component 3D texture 
  14. (intensity component only). Since it is doing an integration through 
  15. space (I'm modeling an xray or radiographic view) I've found that it 
  16. renders best when using an external texture format of 16 bits 
  17. (TX_EXTERNAL_FORMAT : TX_PACK_16) and an internal format of 12 bits 
  18. (TX_INTERNAL_FORMAT : TX_I_12A_4) for intensity.
  19.  
  20. Using 8 bit components causes too much loss of precision for my integration
  21. technique (each component in the integration is typically less than 5
  22. if I want the integral to be clamped to 256). A lot of the image detail is
  23. lost in the roundoff at 8 bits.
  24.  
  25. It would be nice if I could use a dynamically changing texture lookup
  26. function that remapped my intensities. I would like to use the tlutdef()
  27. and tlutbind() calls to do this. Unfortunately, to the best of my
  28. knowledge, it looks likes the texture lookup table routines take my
  29. internal 12 bit texture, truncates to 8 bits, uses the 8 bits as an
  30. index and returns an 8 bit value for the new intensity. This loss of
  31. information is unacceptable for my volume renderer (which is in essense
  32. integrating intensity through depth).
  33.  
  34. I noticed in the man page to tlutdef() that it's entries are 8 bits/component.
  35. It also states that you pass it the number of entries that you want, though
  36. I'm not sure how this parameter affects the results. Anytime I try to
  37. make a table bigger than 256 entries, it seems to ignore anything but
  38. the lower 256 entries.
  39.  
  40. Is there anyway to create a 4096 entry table of 12 (or 16 bit) entries
  41. in a texture lookup table and have my 12 bit/intensity internal format
  42. texture used as an index into this 4096 entry table and have it return
  43. 12 bit values? 
  44. If not, is this a hardware limitation or a software (microcode) limitation? 
  45.  
  46. Also, on a side note, it is my guess that the tlut lookup is done after the 
  47. trilinear interpolation (TX_MAGFILTER: TX_TRILINEAR). Is this true? Is there
  48. anyway to get the lookup done before the trilerp? That is I'd prefer
  49. to have the 8 values transformed by the lookup table and then trilerped
  50. to a single value, rather than trilerp the 8 values and then use this
  51. single result as the index into a single lookup. This makes a difference
  52. because the lookup table is going to model a nonlinear process.
  53.  
  54. PS: Is the reason you don't support a one component internal format
  55. of 16 bits because you only have 12 bits per red/green/blue/alpha in the
  56. framebuffer and so the anything beyond a 12 bit texture component would
  57. be lost anyways?
  58.  
  59. -- 
  60.  
  61.    Tim Cullip
  62.    cullip@cs.unc.edu
  63.