December 4-6, 1995
OpenGL ARB Meeting Notes
Notes taken by Randi Rost, HP
Dave Higgins IBM d...@austin.ibm.com
Jim Miller Landmark Graphics mil...@zycor.lgc.com
Bruce D'Amora GE Medical Systems damo...@med.ge.com
Dale Kirkland Intergraph kirkl...@ingr.com
Bimal Poddar IBM pod...@austin.ibm.com
Pat Brown IBM pbr...@austin.ibm.com
Andy Vesper DEC andy.ves...@eng.pko.dec.com
John Dennis DEC jden...@eng.pko.dec.com
Bill Sweeney SunSoft william.swee...@Eng.sun.com
Tim Misner SunSoft timothy.mis...@Eng.sun.com
Kevin Lefebvre HP kev...@fc.hp.com
Kurt Akeley SGI k...@sgi.com
Randi Rost HP r...@tortola.fc.hp.com
Kelvin Thompson Portable Graphics kel...@portable.com
Bill Armstrong Evans & Sutherland armst...@es.com
Jim Cobb Parametric Technology jc...@ptc.com
Hock Lee Microsoft ho...@microsoft.com
Phil Huxley 3Dlabs phil.hux...@3Dlabs.com
Mike Heck TGS m...@tgs.com
Igor Sinyak Intel Igor_Sin...@ccm.sc.intel.com
Tim Freese NCD t...@ncd.com
Chris Frazier SGI fraz...@sgi.com
John Schimpf SGI j...@sgi.com
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
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.
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).
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 <units> 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.
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.
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.
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).
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.
Value must remain 1 for compatibility. Overloading the value parameter shows a
little ugliness here. Error returned is INVALID_VALUE rather than INVALID_ENUM.
Add a comma after the word "large"
p. 115, Figure 4.1 - Delete "(colorindex only)" from the Logicop box
p. 153 - change TEX_COORD_ARRAY_POINTER to TEXTURE_COORD_ARRAY_POINTER, also
fix this in state table (p. 160).
p. 156 - line spacing of last paragraph is different than others
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
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
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.
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
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
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
GEMS does not clearly benefit (abstain)
NCD would support interleaved arrays
TGS would like to see interleaved array supported if vendors make sure
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
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.
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
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
Hock proposes an ARB vote on whether the 1.1 spec will include PointAndDraw
API or interleaved array API.
PointAndDraw: Intel, Microsoft
Interleaved: E&S, DEC, SGI, IBM
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
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
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
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
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
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)
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
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.
Is the support of GLXpixmaps required for all visuals? This has been discussed
at a previous ARB meeting, and some folks believed that a consensus was reached
that supporting GLXpixmaps was not required. Others don't think there was
consensus on this. This is still an open issue. 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
Pat: the hard part of this is migrating the context between hardware and
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.
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
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
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.
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
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
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
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
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).
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
0.0 0.17 1.0
| | |
V V V
| 00 | 01 | 10 | 11 |
0.0 0.17 1.0
| | |
V V V
| 000 | 001 | 010 | 011 | 100 | 101 | 110 | 111 |
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
Andy 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: