Attendees

List of Handouts

• New Extension - IBM_vertex_array_object Contact: Bimal Poddar poddar@austin.ibm.com
• EXT_rescale_normal Contact: Bimal Poddar poddar@austin.ibm.com
• Issues List for GLX 1.3 Contact: Paula Womack womack@sgi.com
• Vertex Set Proposal Contact: Bimal Poddar poddar@austin.ibm.com

OpenGL++

Overview of Ogl++ Day

1. Recap from Feb. and update from members
2. How do we support multiple APIs?
3. Process discussion
4. Brain dump from David/Mark about design status
5. Spec walk-through with comments

Recap February ARB meeting and update from members

• Is it possible to depart from another point than current spec?
• Is 1 day ARB meeting enough?

Mark: Since last time, we've been investigating things not yet  reflected in the spec such as MP issues,actions, routes — should they intrinsically be built in?  Also fixed spelling of propagate. 

Kevin R.: Since last time, Java3d spec now available to Java licensees. Spec on the web-site. Also definitely plan on creating C++ bindings.

(Promoted by questions from Drew, Bimal, and Mark, Kevin R. coughed up the following...)
Kevin R: In comparing java3d vs ogl++, the following distinctions are noteworthy:

• ogl++ layered on top of OpenGL; Java3d is not tied to a single API (support for OpenGL and Direct3D are planned)
• More of abstraction — no way to jump in the middle
• ogl++ has direct support for fields and routes
• ogl++ allows methods to extend traversal

Jon K.: Aren't important goals:

• make is easier to build 3d applications?
• allow hardware vendors to move up the stack?

Multiple API Discussion

• Legitimacy of ARB to cover scene graph area at all (raised by Drew, Kevin. Answered by Jon K., John S.)
• Problems related to the "wrong" attendees being here (some companies have scene graph experts quite distinct from hardware/rendering crowd at the OpenGL ARB).
• and then: what about multiple API support?

• Lowest common denominator specification (aka "neutral")
• Renderer specific "spec"

Mark: A variant approach is to specify tightly -- but there will be performance costs in converting to the format of the underlying library.

Jim: It's highly undesirable to throw the problem back at the application. So let's explore neutral approach.

Fred: This is a solvable problem -- if one gives up on flexibility.

Paula: Why not just use D3D retained mode?

[This was followed by a short detour into the issues of concerning D3D's driver coverage and developer acceptance. Active participants were John S., Phil H., and Paula.]

David: One of the highest values of extensibility is for folks to use the latest extensions without a new release of the library. The monolithic Performer approach requires a new release of both libraries. Also, extensibility allows us to give customer's the go-ahead to use mechanisms that "good taste" prevents us from allowing into the library.
 
John: There's been a lot of discussion here. We need to break and then vote so we can move on. The underlying requirement was to "not be exclusionary." The basic choices are:

• focus on OpenGL
• lowest common denominator
• separate nodes for each renderer
• extensible only if using OpenGL driver

Mark: This does make the specification process more difficult. Willing to do it -- if this is what folks want.  [Silence followed]

Straw pool was taken with the results (pls check w/ Paula):

In favor: 19
Opposed: 3 (MS, Accelgraphics, Elsa)
Abstain: 7 (intel, sun, hp, & 4 others)

Process Discussion

Tim: Unlike OpenGL, areas of competition/differentiation aren't as clear for a given implementation. Extensions probably have the value, not the API itself.

Kurt: Areas of possible differentation are in platform  tuning and MP support. With Performer, lots of effort in making it work well for a given platform.

Kurt: In order to keep this moving, we need to call a meeting and have an immersive session. And we need to have on-going interaction. My sense is that we need to see a bound in the number of people involved and figure out how to kick off specification effort. The efforts/results of this group need to be visible to this body -- but to be effective the design group needs to be small as well for their working sessions.

John: Can I just ask where people stand in participating in the working group?

Phil: 3d labs is in the middle.
Elsa, HP, Sun, MS: Keep us informed, but...
PTC: interested, but no resources.
Digital: Likely to contribute
Intel: Can contribute. Likely to contribute.
Mitsubishi, Real3d, IBM: Will participate
Intergraph: Think we'll participate.

Mark/David's Overview of Current Specification

David: Inventor went overboard in the object area. Need support for notification (not in spec yet) and set/get.

Valuable to force all geometry and appearance into leaves. OpenInventor programs ended up with lots of separators to wall off state -- which is difficult to optimize around. Performer, on the other hand, was very conscious of how to package state together. They sorted on graphics state to effectively utilize the pipeline.

After David presented the "shape" approach, Jim C. chimed in that the one appearance for multiple geometry approach "works for ProDesigner"

David: Want to allow multi-pass geometry -- or specific ordering or rendering.

David: Traversal model comes from Inventor. Extension mechanism depends on two big things:

• new node types
• new traversals

Dinner Discussions: IBM rep (Suzy?) proposed and met little opposition with Coyote Cafe as place for the
night's meal.

Spec walk-through with comments

Kurt: Need goal/non-goal for modelling support.

Jan: Leaning away from behavior culling?

[Feng rattled off a series of issues. In general, seemed like Mark agreed that the issues needed further discussion.]

• Current route support creates burden -- even when field not referenced in routes
• What about run-time support for sprites?
• What about extending sphere bound to general notion?
• Problem w/ abstraction of norma sets/datasets
• Problem w/ matrix node and transform node. (Mark: should remove these in turn into an "engine")
• Why can't we add fields to appearance nodes?

Jim C: Doc feedback: couldn't make heads or tails out of spline engine.

Jim C: How does one do highlight traversals? (David suggested inserting callbacks that change between traversals.)

Feng: Indexed triangle strip set docs incorrect. Cut/paste error.

David: Perfomer had limited support for indexing. But people really valued separate color indexing.
 
Phil: Can we turn some of these objects into display lists?

David: Possibly. But OpenInventor had a bad experience with this approach. System design center will by dynamic data over static data.

Feng: No notification mechanism in specification.

End of Day 1

OpenGL 1.2

David Blythe described the scene marker extension. The consensus was that this should be moved forward as a common extension by those interested.  ARB vote for including this in 1.2 was 0/8/1 (Aye/Nay/Abstain).

Drew described the status of the range elements extension. He had been asked to go off and think about how this extension could be combined with the compiled vertex array extension. He concluded that this extension really was interesting in its own right, and he recommended against combining it. Microsoft believes this extension is useful, but is willing to move ahead shipping this as an extension. Intergraph, Intel, and AccelGraphics were all interested in this extension. ARB vote for including this in 1.2 was 8/0/1.

We revisited the compiled vertex array extension as well, since the directive at the last meeting had been for Microsoft to go off and try to combine this extension with the range elements extension.  IBM spoke of the need for this extension in an SMP implementation of OpenGL. Bimal passed out a copy of an extension (IBM_vertex_array_object) that goes beyond what is addressed by the compiled vertex extension. After some discussion, we decided to make a list of the problems that the various proposals were trying to solve:

• delayed dereference of data
• single copy of data
• preprocess data
• state independent
• state dependent
• cache data without copy
• fast array configuration changes
• sharing vertexes between primitives
• matching OpenGL++
• address space control

Kevin L. described the occlusion culling spec.  It does not currently support multiple objects, but HP would not be opposed to making the necessary changes. The extension has been implemented and is being used by ISV's. HP has applied for a patent for the occlusion culling technology, but a free license to use the technology would be granted to OpenGL licensees for using this in an OpenGL implementation. ARB vote for inclusion in 1.2 was 0/7/2.

Paula described the packed pixels extension. SGI is the only company shipping this. After a lengthy discussion to educate everyone, we came to the understanding that there was a shortcoming in the spec regarding pixel formats for NT. NT has a preference for pixel data in the formats BGR and BGRA rather than the RGB and RGBA currently defined by OpenGL. Microsoft has already defined and shipped an extension to support BGR and BGRA in the Windows environment. It seems like this is a philosophical issue  -- do we want to make changes to OpenGL that make it work better in the Windows environment, or is it sufficient to have Microsoft provide the capabilities through extensions? ARB vote for inclusion of the BGR and BGRA formats in OpenGL 1.2 was 8/1/0.  (SGI owns this extension spec.)

Randi mentioned a couple of issues that have been mentioned regarding the texture_3D extension. The validity of mipmapping 3D textures has been questioned. In the 2D case, mipmapping is used to create subsequently smaller filtered versions of the original image.You would expect a black and white checkerboard pattern to "blur" to gray as it gets filtered to progressively smaller sizes. In the 3D case, it is not clear that this is the right thing to do, since texels can obscure other texels. You could imagine a 3D texture that has a black surface one texel thick and a white interior.  For the top-level mipmap, you get what you would expect.  For subsequent levels, the object would be blurred to gray, when this may be incorrect.  For a solid texture, the black texels should obscure the white ones for all mipmap levels. It was pointed out that applications could derive the mipmap levels independently and preserve the black border rather than downsampling for each subsequent level.  Kurt said that there has been shown to be a lot of utility in this functionality.  There are many cases where you want to pass a plane through a 3D texture and see a properly filtered result at the plane intersection. But applications that use 3D texture mipmaps for non-transparent data sets should realize that they may not get the results that they expect. The max 3D texture size attribute was also questioned.  This number is pretty useless. (SGI owns this extension spec)

Drew described the status of the paletted texture extension. It hasn't been modified since the last meeting.  SGI would like to see support for a more general internal format of COLOR_INDEX. Drew doesn't think that this would be useful to applications since they wouldn't know how their input data would be mapped into pixel values. Kurt suggested that it might be OK if we don't support the generic COLOR_INDEX token in the list of internal formats.  Pat and Drew both stated that the generic token might be useful for the proxy query function. Another issue is whether at least one format should be required (the current spec does not require this). Alternatively, the spec could specify a minimum color index size. A straw poll revealed a consensus that it should be in the spec but to allow the minimum size to be 0. Paula wanted Drew to make sure that the spec included support for 3D textures. Kurt wanted Drew to make sure that the spec emphasized that the palette was part of the texture object. Is it permissible to do a copy texture subimage? (Microsoft owns this spec.)

The next extension discussed was the texture LOD extension. Pat asks if we want to specify some form of minimal precision for the texture clamping values. Kurt didn't think so.  (SGI owns this spec.)

David B. thought that some of the texture clamp spec should be rewritten in terms of u and v instead of in terms of s and t. This would not change the API, but would hopefully add clarity to the spec.  David will do the rewrite. (SGI owns this spec.)

The key issue for the lit texture extension is where the control resides. Bill A.'s current leaning is to extend the glLightModel call to allow the definition of the specular color to be applied post-texturing.  A second issue is whether the emissive color is grouped with the specular or with the ambient/diffuse components. The general feeling is to define the extension such that a second color is defined, along with an enumerant that defines how the second color is applied after texturing. If lighting is disabled, is this second color always 0? (E&S owns this spec.)

Bimal passed out an updated copy of the rescale normal extension. He had received one comment from SGI, and that was to allow an implementation the option of renormalizing normals if rescale normals was enabled.  This would allow an implementation that does not have a performance penalty for renormalizing to "do the right thing". Kurt suggested that we make this spec very simple and say either you apply such-and-such a function to the matrix or you apply such-and-such function to the normal. The first represents the "rescale normals" case and the second represents the "normalize normals" case. Bimal will modify the extension spec to incorporate the comments that were made. (IBM owns this spec.)

Drew described a minor issue with respect to the range elements extensions. Should there be an implementation-dependent limits to index values? Consensus was to provide a limit, but make it a hint. (Microsoft owns this spec.)

Imaging

Randi went through the list of issues he had compiled for the proposed optional imaging module for OpenGL 1.2.  His recommended resolutions were accepted for all of the issues.  Some of the interesting discussion:

Is there a reason that SGI decided to have pixel transfer operations affect pixel read, write, and transfer operations? David replied that he has seen some applications that use this processing capability (e.g., an electronic light table application that uses processing on readback).  Randi said that it seems like this is a potential source for programming bugs, since the applications generally won't be doing operations like convolution and so on during readback, and so will have to disable all of these operations whenever they call ReadPixels. Kurt suggests that it might be nice to have a single command to enable/disable pixel transfer operations. Since this could be implemented as a utility and since it really isn't feasible to change this behavior at this time, it was agreed to leave it as defined.

The spec says, "If a histogram entry component is incremented beyond its maximum value, its value becomes undefined." The philosophy of OpenGL has been to try very hard to avoid situations where undefined behavior can occur, so do we really want to allow undefined behavior here?  The reason for this statement in the histogram spec was to solve a performance/ease of implementation issue. It was pointed out that if an implementation uses wide enough collectors (e.g., 32-bit counters), there would never be an issue for any practical case.

Kurt observed that the INTENSITY formats are not allowed by the histogram extension. After some discussion, there was consensus that there really was no great need for these, and that is why they were disallowed.

Someone at SGI provided a few written comments on the wording for the convolution border modes extension. Randi will fold these comments into the spec while he is removing the WRAP_BORDER mode.

As far as the mechanism for determining whether the advanced imaging module is present, the consensus was to use the existing extension mechanism. Use ARB_imaging as extension name.  Revs with the spec. Would have a sample implementation and conformance tests. Issue: use ARB prefix or suffix in function and token names? The imaging capabilities would have only upwards compatible changes from this point on.

Kurt would like to weave the descriptions into the document, with an appendix that describes what's been added and what's optional.  Should each occurrence of optional capability be flagged?  This could be onerous.  Is it our intention to make it easy to not implement something or easy to implement it?  Straw poll: 11 favor suffixes, 9 favor no suffixes.  Agreed to add a new token for the extension string that indicates the presence of the imaging capabilities.

End of Day 1

GLX 1.3

Conformance Tests

Dale reported that the OPC group has undertaken an activity to define the tests that an implementation must pass in order to guarantee a certain level of "goodness" for each performance test. Their motivation was to make sure companies pass the OpenGL conformance tests that cover the capabilities used in the performance test.  For instance, they want to ensure that implementations pass the antialiased line test if they report values on the CDRS performance test. There is a problem because some of the tests the OPC wants to require have previously been thrown out of the list of required tests by the ARB. This proposal will be discussed further at the OPC meeting later in the week.

GLU Issues

8. Multiple Threads

It is possible to create a version of the GLU library that is protected against multiple threads accessing the GLU routines at the same time.  Some of the GLU routines such as gluNewTess, gluNewQuadric, and gluNewNurbsRenderer create GLU objects which are then used by the application to modify these objects. In a multiple thread environment, it is [the] application's responsibility to ensure that it uses appropriate locking if multiple threads are going to use the same GLU object. A threadsafe GLU library is such that it will [take] appropriate care in using threadsafe malloc's, etc. internally to ensure that a threadsafe application can run correctly if it uses correct locks, if needed, for GLU objects.

OpenGL 1.2 Schedule

• May 19 - Voting starts on unchanged extension specs
• May 30 - Modified extensions available for review
• June 13 - All extension specs finalized
• July 18 - OpenGL 1.2 spec released
• Aug 18 - ARB meeting to review spec
• Dec 9 - ARB meeting to approve final spec

The OPC group has come up with the following schedule for their meetings:

• Aug. 18-21 in the Bay Area hosted by SGI
• Nov. 3-7 in Austin hosted by Motorola
• Mid-Jan. '98 hosted by HP and Sun in the Bay Area
• May '98 hosted by Intel in the Bay Area

• week of 8/18 hosted by SGI (Bay Area)
• week of 12/9 hosted by Sun (Bay Area)

Vertex Set Proposal

Extensions

Kartik presented Intel's proposed texture scissor extension. SGI has been thinking about similar things but for different reasons (better ways to support non-power of two textures). Again, several companies expressed interest in pursuing the definition of this extension.  Kartik will continue to collect issues.  Paula will make sure this extension spec gets out there with all the other extension specifications.

Drew reported on the status of the multitexture extension.  He got some feedback from E&S but no one else. Microsoft's time frame has changed and they now have more time to work on achieving an extension definition that is unified with the SGI proposal. The place where the two proposals differed the most was in the definition of the texture combine function. Drew believes that his proposal is a superset of the SGI proposal.  Bill A. has some ideas about a really different texture combine function, so he would like to see the proposal as two extensions: one that specifies the combine function and one that specifies all of the stuff that precedes the combine function. The only changes that Drew made to the spec since the last time are nomenclature changes. People should contact Drew with any comments.

FORTRAN90 Bindings for OpenGL

Thanks to IBM for hosting this meeting!