December 4-6, 1995 OpenGL ARB Meeting Notes Austin, TX Notes taken by Randi Rost, HP Attendees: Dave Higgins IBM dwh@austin.ibm.com Jim Miller Landmark Graphics miller@zycor.lgc.com Bruce D'Amora GE Medical Systems damorab@med.ge.com Dale Kirkland Intergraph kirkland@ingr.com Bimal Poddar IBM poddar@austin.ibm.com Pat Brown IBM pbrown@austin.ibm.com Andy Vesper DEC andy.vesper@eng.pko.dec.com John Dennis DEC jdennis@eng.pko.dec.com Bill Sweeney SunSoft william.sweeney@Eng.sun.com Tim Misner SunSoft timothy.misner@Eng.sun.com Kevin Lefebvre HP kevinl@fc.hp.com Kurt Akeley SGI kurt@sgi.com Randi Rost HP rost@tortola.fc.hp.com Kelvin Thompson Portable Graphics kelvin@portable.com Bill Armstrong Evans & Sutherland armstron@es.com Jim Cobb Parametric Technology jcobb@ptc.com Hock Lee Microsoft hockl@microsoft.com Phil Huxley 3Dlabs phil.huxley@3Dlabs.com Mike Heck TGS mmh@tgs.com Igor Sinyak Intel Igor_Sinyak@ccm.sc.intel.com Tim Freese NCD tjf@ncd.com Chris Frazier SGI frazier@sgi.com John Schimpf SGI jsch@sgi.com Day 1 - ----- OpenGL Spec Changes Kurt prepared a handout that contained a brief description of all the changes made to the OpenGL spec as a result of the public review period. I numbered these items to make it easier to reference them from the meeting minutes. The version of the OpenGL spec denoted "2 December 1995 - Interleaved Arrays" was used as the basis for discussion and voting at this meeting. [Ed. note: Kurt recorded all changes to the spec that were agreed to at the meeting. I attempted to capture the changes in these notes as well, but I am not sure these notes are as accurate or detailed as the changes as recorded by Kurt.] 1. Passed 2. Passed 3. Passed 4. Passed (change "nonconvex" to "not convex") Discussion of flag vs. *flag. May require global change. Have a sentence at the beginning to describe the behavior? Revisit if time. Chris notes request for clarification, will generate a proposal for next meeting. Also remove second occurrence of "default" in paragraph above. 5. Passed 6. Passed 7. Passed 8. Passed 9. Passed 10.Passed Still need to fix spelling of "Coodinates". Jim C. points out that there should be an indication in the large OpenGL state machine diagram that the glBitmap call updates the current raster position. Agreed that no change should be made to Figure 2.7 since bitmaps have not yet been discussed at this point in the spec. Is documentation for setting raster pos in window coordinates sufficient? There are lots of questions about this on the newsgroup. The glBitmap call should be used for this, and so the man page for glBitmap should contain a usage note. One coding recommendation is to use glBitmap to move, and after drawing move the raster pos back to the origin. We should be more clear about passing NULL to glBitmap (revisit when we get to the section on the glBitmap call). 11. Passed p. 77 - last paragraph, strike "specified in the range [0,1]" p. 78 - 2nd paragraph, strike sentence "r is the minimum resolvable difference in depth values, again in the same range." (These phrases add no useful information.) Add a period after Eq. 3.7. Should be a float? Yes. The "minimum resolvable difference" is not queriable. Do we need to strike the "specified in the range [0,1]" for the "r" parameter? Kurt has been careful to make it clear that this number depends on the rasterization process, not just the resolution of the depth buffer. If you have 24 bits of precision in the depth buffer, your value for "r" might be 1/2^22 or something like that. You need to do the analysis and determine the value for your implementation - you can't just count the bits in the depth buffer. Consensus amongst people who have implemented this kind of capability is that allowing a query of this value would be bad. 12. Passed Aside: Current extensions are written against the 1.0 spec. It's not trivial to migrate all extension specs to a 1.1 basis. Some existing extensions interact with capabilities that went into OpenGL 1.1. Qu. about table 3.6, p.84 - What is meant for [15..0] on little endian machines? OpenGL spec attempts to avoid discussion of endianness and memory architectures. The [15..0] nomenclature refers to a 16-bit quantity and so the endiannes of the memory architecture is not relevant. Need to state that LSB is bit 0. 13. Passed 14. Passed 15. Passed p.90 - Why is the last parameter of glBitmap defined as "ubyte data[]" instead of "ubyte *data"? Agreed to change this to "ubyte *data" in the spec. If the header file is defined differently, there will be a later vote on whether to change this. Also make this change on pp. 75 and 80. 16. Passed 17. Passed 18. Passed 19. Passed What is the difference between a texture image and a texture array? Texture image is the data that is passed in, texture array is what's stored in the system and accessed during texture mapping operations (includes border). 20. Passed 21. Passed 22. Passed 23. Passed 24. Passed Intention was that subtexture commands are not allowed to modify the border unless a border was specified in the texture image. p. 99 - Last sentence delete "argument" from "any of the following argument relationships..." Also make same change in 2nd paragraph on p. 100. How is the term "pixel groups" being used? The discussion starts on p. 93. A pixel group is definitely not a fragment. There is an inconsistency in the use of "element" between vertex array and pixel rectangles. The editing was too far along when this was discovered to worry about it. p. 103 - Change wording of last paragraph. 25. Passed 26. Passed Value must remain 1 for compatibility. Overloading the value parameter shows a little ugliness here. Error returned is INVALID_VALUE rather than INVALID_ENUM. 27. Passed Add a comma after the word "large" 28. Passed 29. Passed p. 115, Figure 4.1 - Delete "(colorindex only)" from the Logicop box 30. Passed 31. Passed 32. Passed 33. Passed 34. Passed p. 153 - change TEX_COORD_ARRAY_POINTER to TEXTURE_COORD_ARRAY_POINTER, also fix this in state table (p. 160). 35. Passed p. 156 - line spacing of last paragraph is different than others 36. Passed 37. Passed 38. Passed 39. Passed p. 185, C.2 - Change "They also will be used..." to "They may also be used..." p. 186, C.6 - remove "are specifically encouraged" and change "Mipmap" to "mipmap" p. 187, C.9, item #7 - Change formatting of "ColorMaterial" p. 187, C.9, item #4 - Incorrect macro usage "chapter refframebuf..." Acknowledgements - add Andy Vesper - DEC, Pat Brown - IBM Discussion of internal formats (table p. 94) - Should others be added? Some deleted? Various opinions. A couple of votes expressed for supporting RGB 3-3-2, RGB 2-3-2-1, RGB 5-6-5. RGB2 would likely be mapped by implementors to RGB 3-3-2. Agreed to remove RGB2 and replace it with R3_G3_B2. Agreed that adding RGB 5-6-5 was not necessary since RGB5 is already supported. Agreed that adding RGB 2-3-2-1 was not necessary since RGBA2 is already supported. Discussion of pointer arithmetic being based on size of a FLOAT. This was done to make spec more precise, but perhaps there are some architectures where the size of GLubyte is the same as the size of GLfloat (Cray?) and this pointer arithmetic would not work properly. Kurt will attempt to define a value f that is the size of 4 GLubytes rounded up to the next floating point word boundary. That defined value will be used to replace the "sizeof(FLOAT)" constructs on pp. 25-34. Definitions: Basic vertex array - What was in the licensees review draft Packed primitive - What was in public review draft Interleaved array - Modifications due to comments during public review Point and draw - proposed at the Dec. '95 ARB meeting PointAndDraw(mode, format, count, *data) mode - TRI, QUAD, ... format - V2F, V3F, C3F_V3F, ... Should there be a DrawInterleavedArrays call? This would be one call that sets up the mode, format, strides and draws the arrays. Some argue that this is "cleaner" because it avoids modifying the remainder of the client-side state for vertex arrays. Others argue that this is not really offerring any improvement over the currently proposed spec. The single call may not provide enough flexibility since there is no way to modify color materials. There is a continuum going from ultimate flexibility (i.e., immediate mode) to ultimate performance. How many points should we provide along this line? Discussion at break caused the following table to be developed: Share Share Drawing Generality State Commands (1 is best) basic vertex array no -- 1 packed pointer no yes 3 interleaved array yes yes 2 point and draw no no 4 Straw vote: How many would favor going beyond the basic vertex array capability? About 9 How many would not favor going beyond the basic vertex array capability? About 6 Poll of ARB members: E&S would support interleaved array Microsoft would only do basic vertex array Intel would only do basic vertex array IBM would do interleaved array Intergraph would only do basic vertex array DEC abstains SGI would do interleaved array Poll of non-ARB members: HP would support interleaved array Sun would support something beyond the basic vertex array, so votes for interleaved array GEMS does not clearly benefit (abstain) NCD would support interleaved arrays TGS would like to see interleaved array supported if vendors make sure it's blazin' 3Dlabs would favor point & draw, but would like something beyond basic vertex array in 1.1 PTC would like to see interleaved arrays supported How many ARB members would vote against the spec if it included interleaved array? 1 (Microsoft) Current definition of interleaved arrays in spec is gross, spelling out exactly how every format works. Kurt wanted to make in abundantly, incontrovertibly clear that there was nothing "special" going on in these calls. Perhaps do one or two in gory detail and leave the others as an exercise to the reader. A small subgroup will meet after adjournment to come up with a proposal for modifying this. Should the format C3F_N3F_V3F be added? There is a C4F_N3F_V3F. Interesting that there is a C3F_V3F but not a C4F_V3F. Would be useful if there was a way to reserve enumerated types for formats in extensions were in the same space as the "standard" set of formats. Day 2 - ----- Kurt passed out a proposed writeup for the interleaved arrays pseudocode and definition table. p. 84 - bit 0, was there a change here? p. 103 - last paragraph, change "with unspecified value" to "with i < -b_s, j<-b_s, i >= w_s - b_s, or j >=h_s - b_s" p. 183 - delete corollary #19 p. 78 - 3rd paragraph, delete last sentence ("Vertex z_w values...") and delete the z_w from the preceding sentence. p. 34 - The description of pseudocode for glRect is correct in the absence of error conditions. Should this be clarified? Hock wants to loosen error semantics. This is a larger discussion and could be done later. We'll defer this for now. Is it ok to leave GL state indeterminate after DrawArrays? Straw vote: 15 yes, a couple no p. 19 - 3rd paragraph - glPixelStore is added to the list which has a caveat for the error of being within a Begin/End. p. 39 - For glFrustum and glOrtho, if near=far, or left=right, or top=bottom, an INVALID_VALUE error is generated in all known implementations. This is not documented in spec or man pages. Add the phrase "l is equal to r, b is equal to t, or n is equal to f" just before "the error INVALID_VALUE" results. Insert the sentence "If l is equal to r, b is equal to t, or n is equal to f, the error INVALID VALUE results," just before "The corresponding matrix is..." for the glOrtho call. p. 92 - Parenthesize the last full sentence, "For compatibility with the 1.0 version..." p. 34 - 1st paragraph - Change the sentence that begins, "In the initial state..." to read, "In the initial state the boolean values are each disabled, the memory pointers are each null, the strides are each zero, ..." p. 30 - Should SeparateArrays be included 1.1? Bill would like to keep it. Hock still thinks all this stuff is premature, since we have no real application experience. John D. agrees with Bill and thinks that we have application experience that helps us here. Hock argues for PointAndDraw. Others point out that it isn't as flexible as the interleaved array proposal. Hock doesn't think the extra flexibility is worthwhile, others do. Hock also argues that PointAndDraw is easier to use. Randi asks if it really helps ease-of-use. Should people confused by the interleaved arrays really be using OpenGL rather than some easy-to-use middleware? Kevin argues that interleaved array is two calls, PointAndDraw is one. People will live within the interleaved arrays model and never deal with vertex arrays, strides, enables, etc. This is no more difficult to understand than the one PointAndDraw entry point. John D. echoes Randi in saying that the design center for OpenGL is not ease-of-use, but efficient access to hardware features for 3D graphics and imaging. Kurt states that OpenGL is a power tool. PointAndDraw support: Microsoft, Intel, 3Dlabs More discussion. Hock proposes an ARB vote on whether the 1.1 spec will include PointAndDraw API or interleaved array API. ARB vote: PointAndDraw: Intel, Microsoft Interleaved: E&S, DEC, SGI, IBM Abstain: Intergraph Should PointAndDraw be in the 1.1 spec? Yes: 2 Should interleaved and separate arrays be in the 1.1 spec? Yes: 5 Dale says Intergraph wants something, and since PointAndDraw was defeated, he votes for interleaved arrays. Should separate arrays be in the 1.1 spec? Yes: 3 E&S, SGI, DEC p. 25: Everything after "If format is one of these..." in the second paragraph is deleted, up until p. 34 where the pseudocode ends. The first paragraph of prose is retained. Deleted text is replaced with the text and table handed out by Kurt. p. 184: Delete the second occurrence of DMA (last line of page). In the marginal notes, replace "one of 14 pre-defined..." to "one of the pre-defined". p. 160: delete packed array state (last four lines) p. 19: 3rd paragraph - Change "...and VertexPointer is not allowed to..." to "..., VertexPointer, InterleavedArrays, and PixelStore is not allowed to..." Vote on spec as amended as the spec for OpenGL 1.1: Yes: 7 No: 0 OpenGL 1.1 spec is approved! YEE-HA! Next meeting is in Seattle (Microsoft host) Feb. 26-27. Meeting after that is tentatively scheduled for May 6-7, in Boston with DEC hosting. Hidden surface methods other than depth buffer DEC is interested in supporting OpenGL on architectures that support a hidden surface method other than depth buffering (most likely, a scan-line algorithm like Watkins). What's affected? multi-pass with depth test equal polygon offset no frame demarcation (begin/end frame) Kurt: Two obvious things to do: 1) try to fudge things up so that OpenGL user doesn't notice much (any) difference 2) add something explicitly to OpenGL Deciding which approach to pursue is a very important question. John: cost of memory for depth buffer may drive vendors to develop architectures that support something other than depth buffering. Kurt: This issue came up as soon as the Apple paper was published (SIGGRAPH '92, p. 241?). Jim C: Would you not have a stencil buffer? John D: Good question. Probably just disallow stencil buffer modes that depend on depth values. Kurt: OpenGL works great for middleware that does it's own hidden surface algorithm - just turn depth test off. John D: Right, but OpenGL does not currently help if the algorithm is accelerated by hardware. Kurt: Can't figure this out in the abstract, need to define the device. Seems like you really need to define objects if you're doing a BSP-tree or something similar. Kurt: OpenGL is procedural, not descriptive. In a descriptive API, you describe your desired end result and let the system do it for you. Vendors could implement a variety of ways to support this. But this isn't how OpenGL works. In OpenGL, you dictate the steps to be taken to get the result that you want. If you have hardware that is fundamentally different than the OpenGL model, you will need a different API. You may be able to call it OpenGL, but it seems like a long shot to hope that such support could be added to OpenGL with minimal API impact. John D: Well, let's try to focus a little more. Let's just think about possible support for scan-line algorithms. This seems like the most doable. glFlush could be the event that would indicate you need to run the hidden surface algorithm on the accumulated geometry. glClear could be the event that sets the accumulated geometry list to NULL. glFlush would *not* do an implicit glClear to reset the accumulated geometry list to NULL. Pat: Wouldn't it be cleaner to have new versions of clear and flush that are specific to these capabilities (i.e., a new extension)? Jim C: I think so. App developers currently think the glFlush call is relatively cheap. John D: Would like to do this with the minimum amount of application rework. Would like apps to work out-of-the-box without changes as long as they don't have anything in them that assumes the ability to read or write the depth buffer. John D: What if the market force is not OpenGL, but games? What if boards without depth buffers can be made cheaply? Isn't it in our best interest to figure out how to support OpenGL on these types of devices? It will always be cheaper to build a board without memory for depth buffer. Randi: I'm still not sure that what you've said rules out the approach of a new extension that defines exactly the capabilities you want. It may very well be better to provide new entry points that do the right thing, rather than try to wedge support in through existing API calls. If it is so important, this extension would become mainstream very quickly. John D: How many people would have an interest in pursuing this path? (12-14 hands are raised) (more discussion) John D: We'll right up a proposal and post it to the net for discussion. I'm walking away with a couple of thoughts. People do think this is important, and it seems like there is some likelihood that this could be supported in OpenGL. Kurt: I assert that it's bandwidth that's the real cost here. Doing depth-buffering triples your bandwidth requirement - you need to both read and write the depth values during a rendering operation. Having enough memory for the bits is not that big of a deal. If you can just jam the color value in the frame buffer, it's a lot easier/cheaper (requires a lot less bandwidth). GLX 1.2 Spec: Not clear whether we can reach closure on this spec at the meeting. Paula is the document editor, and she was unable to attend this meeting, so it may require letting some wordsmithing occur after the meeting. All issues could be resolved, but a final copy of the GLX 1.2 spec would have to be prepared and sent out, followed by an email vote to ratify it. Paula linked in by phone. Agreed to modify the protocol document to enumerate the list of commands that can generate a BadCurrentWindow error. Is the support of GLXpixmaps required for all visuals? This has been discussed before, and it was agreed (sort of?) that GLXpixmap support was not required. Let's nail this down and put a statement in the spec so that there's no more ambiguity. Some vendors (IBM, E&S) are shipping an implementation of OpenGL that does not support GLXpixmaps of any type. Is indirect rendering required? Previously agreed that if the window system supports indirect rendering, then your OpenGL implementation must support it. John D. thinks a fair reading of the spec leads to the conclusion that indirect rendering is required. Bruce: We (GEMS) would rather see vendors put effort into supporting pbuffers than GLXpixmaps. Pat: the hard part of this is migrating the context between hardware and software renderers. Straw vote: Those in favor of adding a statement that support for indirect rendering is required? Yes: 13, No: 1 Now, what is the definition of indirect rendering? Straw vote: Those in favor of adding a statement that a conformant GLX client must be able to properly generate GLX protocol and that a conformant GLX server must be able to properly receive and execute GLX protocol? Yes: 13, No: 1 John and Paula will wordsmith a conformance statement. Straw poll: Should implementations be required to support all GLXpixmaps? Yes: 5 No: 11 Should implementations be required to support at least one type of GLXpixmaps? Yes: 6 No: 7 Should GLXpixmap support not be mandated? Yes: 8, No: 6 More discussion One of the hardest issues to deal with is dealing with the need to use the same context with both windows (that are supported by hardware) and GLXpixmaps. Rather than blow off support for pixmaps, why not just implement a policy that prohibits the use of the same context with windows and GLXpixmaps? John will pursue wordsmithing a statement that GLXpixmaps are supported, but that there may be an error that occurs when a context is made current with a "dissimilar" drawable, or when a rendering context is copied to a "dissimilar" rendering context. Implementations might implement this by keeping state identifying whether the context was last bound to a window or a GLXpixmap. Perhaps we want to add a query to obtain which visuals support pixmaps (i.e., through config attributes?) Are GLXpixmaps double-buffered? Need to clarify this in the spec. Kurt contends that it was always his intention that if a pixmap was created with a double-buffered visual, then the pixmap would be created with both front and back buffers. Intention was that any program that ran on a window would also run on a pixmap. Perhaps a program wants to use pixmaps to create its image for printing. It seems like if you say you support pixmaps for a visual type that is double buffered, that type of pixmap should have both front and back buffers. Don't say you can create a pixmap for a visual type that you really can't (i.e., don't lie). Proposal for adding a config attribute PIXMAP_SUPPORT. For each visual, vendor decides whether this visual can be used to create a GLXPixmap. Caution: How far down this path should we go? There is movement to redo all of this stuff (FBconfig extension). We need to reach a consensus on GLX 1.2 quickly so that we have something that binds with OpenGL 1.1. What gets returned when you do a QueryContextInfo on a share list that has come from multiple contexts? The notion (not explicit in the doc) is that display lists can be formed into pools. Perhaps this should be described. On top of p. 3, the doc talks about client side state and server side state. It should go further here and define names for these things and describe how the XID's relate to these state objects. Without this, the rest of the document is unclear. Suggestion is to make GLX_SHARE_CONTEXT a boolean. Kurt notices that glXCreateContext should probably be passed an XID for the share list rather than a GLXContext. Oh well. Another suggestion is to delete the GLX_SHARE_CONTEXT completely. Several people support this. John D. will talk to Paula and try to ascertain whether there was any compelling reason for this capability that we're overlooking. p. 19, Last paragraph - Change the last two sentences to read, "Finally, note that the buffers for drawable need not be allocated until they are needed. A BadAlloc error will be generated if the server does not have enough resources to allocate the buffers." Should MBX be mentioned along with DBE? No. The parenthetical statements in the second to last paragraph seem to set the stage for relaxing the current restrictions on binding rendering mode and visual types. Should this paragraph be modified to make it more clear that this area will likely change in the future? Should we just say GLX 1.2 is nothing more than the changes needed to support OpenGL 1.1? This has some merit to some folks. We would need to include the text about texture objects. Straw poll: Who would prefer to do GLX 1.2 ASAP just to support OpenGL 1.1, followed by GLX 1.3 that includes more capabilities regarding visual selection? Yes: 12, No: 0 Folks want a GLX 1.2 review document with change bars relating to the GLX 1.1 doc. Issues list for GLX 1.3: 1. Mandate indirect rendering (what's conforming?) 2. Distinguish client and server contexts (and combinations) 3. Define off-screen rendering (using pixmaps) if it is implemented (rebinding, copy context similarity issues, all visuals?) 4. Add pbuffer support 5. Share list query 6. Not possible to share lists when not sharing a GLXContext address space 7. Add FBConfig capabilities (relax X visual / GL renderer matching) - Create a real GLX context, not just additional parameters tagging onto an X visual 8. Keep all proposed 1.2 additions (e.g., import context) 9. Get Create/Destroy semantics correct 10. Correct bit-count-in-color-buffer terminology Jim C. passed out a hand out representing a brain dump on blend modes. We want a blend mode that will cause a line to brighten as it is drawn over itself. Bill: The OpenGL stuff works if you have a black background, but not a background of a solid color other than black. Jim: Dissolve OVER, Comp OVER, Dissolve REPLACE, Comp REPLACE are the performance critical ones for us Kurt: Perhaps this is a capability where we need to think about the topic of subsets in OpenGL. The pain threshold is just too high to add new blend modes to devices that don't support them in hardware, and this creates a barrier for getting these kinds of things in OpenGL. Jim C: Q: Are people interested in this? Developing a common extension? A: Yes Jim C. will work over the handout and post something to the newsgroup to start discussion. A Conversion Diversion - ---------------------- (Kurt may be able to provide additional clarity here if I haven't captured the discussion adequately.) There are some subtleties to conversion of color components that may not be obvious to all. First, the spec clearly states (Table 2.8 in the V1.1 spec) that to convert integer color components to an internal floating point format, you use an equation of the form: Eq. 1: e = a/2^n - 1 where: n is the number of bits in the incoming integer color component value a is the incoming color component value e is the resulting floating point representation of the value Second, the last paragraph at the end of chapter 2 of the spec states: "Because a number of the form k/(2^m - 1) may not be represented exactly as a limited-precision floating-point quantity, we place a further requirement on the fixed-point conversion of RGBA components. Suppose that lighting is disabled, the color associated with a vertex has not been clipped, and one of Colorub, Colorus, or Colorui was used to specify that color. When these conditions are satisfied, an RGBA component must convert to a value that matches the component as specified in the Color command; if m is less than the number of bits b with which the component was specified, then the converted value must equal the most significant m bits of the specified value; otherwise, the most significant b bits of the converted value must equal the specified value." It turns out that if you do the conversions as specified by Eq. 1, you cannot satisfy the requirement stated at the end of chapter 2. [begin example added after the meeting by note taker] Input color component is an unsigned 16-bit luminance (single component) value: Hex Decimal Binary D554 54612 1101 0101 0101 0100 Converting this to a floating point value for internal use according to Eq. 1 gives a value of 54612/65535, or approximately 0.8333257. Converting this value in order to store it in a 10-bit color buffer according to the OpenGL spec: floor(0.8333257 * 1023 + 0.5) = floor(852.4922 + 0.5) = 852 The number as represented in this 10-bit space is: Hex Decimal Binary 0354 852 11 0101 0100 The requirement at the end of chapter 2 is not satisfied since the first 10 bits of the original value are not identical to the result (11 0101 0101 is not equal to 11 0101 0100). [end example] Kurt says he likes to think that integer values are really just names for exact values. You take all incoming values and convert them to the exact value they represent. The converted values are in some floating point representation that you've defined for your architecture. If you use Eq. 1 to convert from a space with fewer bits to a space with more, the bit values in the smaller space will exactly match the equivalent bit values in the larger space. If you use Eq. 1 to convert from a larger space to a smaller space, the bit values in the smaller space will not always precisely match the equivalent bits in the larger space. The following diagram illustrates this issue (within the limits of ASCII art). Fig. 1A illustrates how floating point values are mapped into a space with a resolution of two bits per component. Using Eq. 1, the input value that is equivalent to 0.0 will map to the middle of the first "bucket" (bit representation 00). The value 1.0 will map to the middle of the last "bucket" (bit representation 01). Values between 0.0 and 1.0 will be mapped linearly between the positions into which 0.0 and 1.0 are mapped. Fig. 1B illustrate how floating point values are mapped into a space with a resolution of two bits per component. Again, 0.0 is mapped to the middle of the first "bucket" (000) and 1.0 is mapped to the last "bucket" (111). Notice, however, that the boundaries between buckets do not always line up as you might expect. The boundary between 00 and 01 in Fig. 1A does not line up with the boundary between 001 and 010 in Fig. 1B. A value like 0.17 will map into the "01" bucket in Fig. 1A, but will map into the "001" bucket in Fig. 1B. The first two bits are not identical in this case, which means that the requirement at the end of chapter 2 is not satisfied. 0.0 0.17 1.0 | | | V V V --------------------------------------------------------- | 00 | 01 | 10 | 11 | --------------------------------------------------------- Fig. 1A 0.0 0.17 1.0 | | | V V V ------------------------------------------------- | 000 | 001 | 010 | 011 | 100 | 101 | 110 | 111 | ------------------------------------------------- Fig. 1B Another conversion/representation method is possible, namely: Eq. 2: e = .aaaa... suppose n=4, a= 1101, then e= .1101 1101 1101 1101.... This method will obey the caveat at the end of the second chapter. However, spec is clear that you use Eq. 1 to convert values. Caveat at end of second chapter causes inconsistency in spec. "Leading bits will maintain consistency regardless of the name space." If you use Eq. 2, you will satisfy the caveat. The histogram extension was carefully written to use Eq. 1. Kurt feels that the best equations to use are a=floor(e(2^n-1) + 0.5) and Eq. 1. This means the requirement at the end of chapter 2 will not be satisfied. John D. says that a related issue is that when you do a component conversion from a signed value to an internal floating point representation according to the OpenGL rules, an input value of zero will map to a value that is nonzero in the internal floating point representation. (For instance, if the input value is a signed short equal to zero, the conversion will be (2*0 + 1)/65535 = .0000153.) DEC has heard from a couple of users that this is a problem. Is this an issue for anyone? Kurt says that scale and bias can be used to convert from a signed component space to an unsigned component space. Perhaps people should be encouraged to use the scale and bias to avoid this issue. Thanks to IBM for hosting. Thanks to everyone for helping complete OpenGL 1.1! Next meeting topics: GLX GLS