ARB Meeting
Notes ARB Meeting
NotesHosted by Digital-Megatek in San Diego, CA
Meeting notes taken by Randi Rost, HP
| Dale Kirkland | Intergraph | kirkland@ingr.com |
| Randi Rost | HP | rost@fc.hp.com |
| Kevin Lefebvre | HP | kevinl@fc.hp.com |
| Bill Sweeney | Sun | sweeney@eng.sun.com |
| Henri Warren | DEC | warren@rbc.dec.com |
| Igor Sinyak | Intel | Igor_Sinyak@ccm.sc.intel.com |
| Pat Brown | IBM | pbrown@austin.ibm.com |
| John Schimpf | SGI | jsch@asd.sgi.com |
| Phil Huxley | 3Dlabs | phil.Huxley@3Dlabs.com |
| Jim Cobb | Parametric Technology | jcobb@ptc.com |
| Kurt Akeley | SGI | kurt@sgi.com |
| Otto Berkes | Microsoft | ottob@microsoft.com |
| Bimal Poddar | IBM | poddar@austin.ibm.com |
| Bill Armstrong | Evans & Sutherland | armstron@es.com |
| Bill Clifford | Digital | clifford@bgsdev.zko.dec.com |
| Dick Jay | Template Graphics Software | jay@tgs.com |
| Mike Quinlan | Real3D | quinlanm@real3d.com |
| Stefan Seeboth | ELSA | se@elsa.de |
| Rob Putney | IBM | rputney@vnet.ibm.com |
| Fred Fisher | AccelGraphics | agi-arb@ag3d.com |
| Kartik Venkataraman | Intel | kvenkat@gomez.sc.intel.com |
| Bill Mitchell | NIST | william.mitchell@nist.gov |
| Paula Womack | SGI | womack@sgi.com |
| Mark Segal | SGI | segal@sgi.com |
| Kevin Rushforth | Sun | kcr@eng.sun.com |
| Steve Wright | Microsoft | swright@microsoft.com |
| Hock San Lee | Microsoft | hockl@microsoft.com |
A release of the Sample Implementation of OpenGL (version 1.1.1) is planned for December. The exact release date depends on the outcome of discussions at this meeting. The biggest change is the inclusion of a new NURBS tessellation algorithm which results in crack-free NURBS. SGI also plans to ship some GLU extensions that they've implemented (these will be discussed later in the meeting.)
Item #1: Passes 9-0-0
Item #2: Mark S. states "It wasn't necessary for the spec to state explicitly that PixelMap values are clamped because they eventually are clamped by subsequent operations." Since some operations have been added by extensions, it seems to be necessary to state that the values are clamped when specified. Pat points out that this also affects Figure 3.7 of the June '96 spec. Bimal asks if you wouldn't also have to mask index entries. This item was tabled since it wasn't as obvious as it first appeared.
Item #3: Passes 9-0-0
Item #4: Passes 9-0-0
Item #5: Paula advocated making no change to the spec.
Item #6: Passes 9-0-0
Item #7: Passes 9-0-0
Item #8: Passes 9-0-0
Item #1: Passes 8-0-1
Item #2: Lengthy discussion. The ability to put specific values directly in the frame buffer has great utility, but it is difficult to specify. Tabled.
Item #3: For points, you don't have to worry about interpolation. The only real problem occurs when q=0. But implementations may have a problem dealing with negative q values since they are not permitted for lines or polygons. Passes as written 9-0-0.
Item #4: Kurt says, "The rule that's always been implicit in our heads is that the rasterization of a primitve always results in zero or one fragment per pixel. Funny stuff can happen if rasterization produces more than one fragment per pixel." The type of issue represented by the first part of the discussion is pervasive to the discussion of antialiasing in the spec. No good support for pursuing a solution to the first part of the discussion. Proposal: for the last sentence in 3.4.2, add "and polygon offset fill" to the list in the parenthetical statement. But you really should also say that polygon offset line can be applied. This creates a complex parenthetical statement and forward reference. Mark offered to come up with an alternate proposal. Tabled.
Item #5: Disposed of by resolution to Item #1 in Paula's list of spec issues.
Item #6: Mark will take a look to see if a wording change is warranted.
Item #7: It seems as if the question should be, "If you are in color index mode" rather than "If 'if' is a color index...." Mark will take a look to see if a wording change is warranted.
Item #8: Not a spec issue. Paula will look at the SI and make a proposal.
Bill Mitchell of NIST gave a presentation on the need for a FORTRAN90 binding for OpenGL. He distributed a paper that described the current proposal for a FORTRAN90 binding for OpenGL.
Why a FORTRAN90 binding?
Major differences from existing binding:
Proposed Interface Procedures
Proposed Interface Defined Constants
Reference Implementation
After the presentation, the following issues were discussed:
Item #1: Bimal to come up with a proposal, modifying Fig. 2.2 in such a way that it could be used as Fig. 2.7.
Item #2: The general treatment of errors is described in one spot, and covers these cases. No action is required.
Item #3: Might have been better to specify that reversing the order of the vertexes will reverse the sense of the face. But it doesn't seem to be worth changing at this point. This seems like a spec detail that implementors would ignore if it made the implementation difficult.
Item #4: Yes, there is a problem in the wording here. Bimal will write out a proposal for discussion.
Item #5: This discrepancy was known, can't really remember if it was intentional. Seems like this got specified in two places and was specified inconsistently. It's too late to do anything about this though. Bitmaps and lines work similarly, pixel locations and polygon vertices work similarly.
Otto discussed the issue he raised in his email message. The Alpha processor is pretty sensitive to NAN values. Kurt says that the spec was written the way it was because SGI had experience with real world data that contained NAN's and needed to be digested without crashing the system. A motion to modify the conformance test as proposed was passed 9-0-0.
HP, SGI, and E&S passed out extension specs that addressed the issue of specular highlights on textures.
Bill A.: I'm floating a proposal from E&S in order to see who's interested in this problem, not that it necessarily has to be done the way I've proposed.
Kevin L.: The HP proposal is what is implemented in PEX to satisfy customer requirements, and the proposed OpenGL extension would carry this capability forward into the OpenGL environment.
Paula: The author of the SGI proposal wanted to write up a spec that covered all the issues, and then see if it made sense to split out some simple parts into separate extensions.
Kurt: One of the thing that I like about the SGI proposal is that it completely separates the notion of fragment lighting from vertex lighting, and it doesn't drag along the big wad of state associated with vertex lighting.
Volunteers to work out a common proposal are: Dale (Intergraph), Pat (IBM), Bill A.(E&S), Henri (Megatek), Kevin L. (HP), Fred (AccelGraphics), Kartik (Intel), Bill S.(Sun), Otto (Microsoft), David Blythe (SGI).
Kurt: This feels like it should be more "lighting-oriented" than "texture-oriented" and the group should look at whether following this approach would paint us into a corner in terms of dealing with multiple textures or other related issues in the future.
Kevin L.: I want something simple that can be implemented and be compliant, even if the overall proposal includes additional capabilities.
Jim would like to see a way to cause zero area polygons to be completely disregarded. Applications might want this in order to send some "disconnected" geometry as a single triangle strip. Kevin L. and Bimal say that it's probably a performance hit to do things this way, because you're sending a lot of bogus data (the zero area polygons). No real consensus that Jim's proposal would be useful. People are encouraged to contact Jim to discuss this further.
HP, SGI, Sun, and Intel have indicated some interest in imaging extensions. How do we proceed? Not all vendors will want to support this functionality, so we'll either have to have a more formal extension sharing mechanism or we'll have to work toward a 1.n OpenGL spec that allows subsetting.
Kurt: What is needed to establish a more formal mechanism? Man pages, conformance tests, a sample implementation...?
Randi: We could have a way of "branding" a set of extensions...for instance the "advanced imaging extensions module." It would be easier for application developers to deal with a big set of extensions rather than dealing with a bunch of tiny ones.
Kurt: We need someone to develop a proposal for a higher level of cooperation on extensions.
Paula: I would be against a 1.n that is subsetted. Applications benefit from the fact that all OpenGL implementations contain all of the OpenGL capabilities.
Pat: We were burned by changes in some EXT extensions.
Fred: Extensions should have versions.
Paula: Checking versions on extensions can be a big burden for application developers.
Straw poll: How many ARB members would be strongly inclined to vote for a 1.2 with imaging if SGI provided "the usual stuff"? This 1.2 spec would possibly include the following extensions: convolution (EXT), histogram min/max (EXT), color tables (SGI/EXT), image transform (HP), and color matrix (EXT). Five votes. How many would be strongly disinclined? Zero. How many others be convinced depending on the content? Four. How many people would be inclined to vote for a 1.2 if the imaging stuff was optional? Eight.
John: People should come to the next meeting prepared to talk about what will go into OpenGL 1.2.
Kurt: What's nice about this is that it doesn't require us to invent a new process.
John: Does someone want to own this (e.g., be the focal point for collecting input and coordinating the specification effort?)
Randi: I will.
Bill S.: We've had some customer requests for the existing imaging extensions. We're doing OpenXIL, and we want to make sure that what we build is compatible.
Paula: I'd like to find out how people felt about the GLX extensions that we had tried to put on a fast track: pbuffer and FBConfig.
Kevin L.: Because of our product development schedules, HP hoped to finalize these quickly, but we missed the window so we're in no hurry now...having these in the next release of OpenGL is fine.
Paula: It sounds like adding these extensions to GLX in the same time frame as an OpenGL 1.2 would be the right thing.
Mark Segal presented SGI's ideas on creating a scene graph manipulation toolkit for OpenGL.
Why A Layer Above OpenGL?
Cosmo3D
Inventor
Performer
Why Not Performer/Inventor
Cosmo3D Is...
Cosmo3D Is Not...
Cosmo3D So Far
Fields, Routes, and Engines
Some Other Related Work
What We Need
Kurt: I think this group should work on this problem because the group has shown that it is able to work together to advance technology. It is also clear that this area will affect the evolution of OpenGL.
Hock: Will other proposals be entertained?
Kurt: Absolutely. This was not an "SGI proposal" to do Cosmo3D. We just wanted to tell people what we're doing in this area and find out if the ARB wanted to develop a specification for this type of functionality.
Kurt: SGI's goal is to create an environment in which applications could use a variety of libraries (where OpenGL provides the common foundation) to accomplish their tasks. Right now, SGI customers have to make a choice about which library to use, and the libraries don't interact with each other.
Hock: When could this be shipped?
Kurt: This group could do a spec in about a year, I think?
Hock: So commercial products would not be available till '98?
Kurt: It may not be like OpenGL because it doesn't require hardware acceleration...companies may be able to ship it more quickly. A sample implementation may not require as much re-implementation as an OpenGL implementation.
Kevin R.: Shouldn't we make sure this can be layered on top of other graphics APIs?
Kurt: Yes we should. It seems likes it would be in the best interests of this group to define something that works really well on OpenGL. As you write a tighter and tighter spec, you find yourself making really hard choices.
Kevin R.: Should this group do this or should another body be formed?
Kurt: This group needs to think about that. I would prefer not to go through the licensing effort again, since it was really, really difficult to get legal agreements in place between a number of companies.
Kurt: As the level of the functionality provided by a vendor increases, it becomes possible for that vendor to "hide" access to extensions. This can be a way to provide more and more capabilities to applications without requiring them to access extensions directly.
Bill A.: E&S has a product in this area (Integrator), so we'd be very interested in seeing this evolve in a way that is consistent with what we already support.
Igor: Intel has a library (Intel Scene Manager) that addresses similar concepts.
Dick: Would SGI turn over the technology to the ARB?
Kurt: We have to be careful to turn over only our technology, but yes, that would be an easy discussion to have. We're also ready to turn over the manpower to implement whatever spec the ARB came up with.
Kurt: I would propose that we not make the list too long for what we're trying to accomplish in the first release. We should have a long list of things that we'd like to do eventually and we should think about those things as we write the spec, but we need to bite off a reasonable chunk for the first release.
Jim: Some ISV's have their own scene graph stuff -- PTC has their own.
Kurt: We've heard vendors say, "We have this scene graph stuff and we'd really like not to."
Hock: I'd like to see this layered on OpenGL, like GLU.
Kurt: There are two examples: GLU and GLS. I think that this is more like GLS. GLU is a required part of the OpenGL environment.
Fred: Does GLU or another higher level library take advantage of undocumented hooks in your OpenGL implementation?
Kurt: No. All access is through documented entry points in OpenGL or extensions.
Otto: How soon could a sample implementation be done by SGI?
Kurt: We're in the (unfortunate) position of being able to provide an implementation sooner than a spec. We need to get the cart back before the horse and make sure we do a spec that contains what we want. On the other hand, since we have an implementation in progress, this stuff isn't just a bunch of hot air.
Straw poll: Would you be in favor of having the ARB own the specification of a scene graph standard? 21 in favor, 2 not interested, 1 concerned with whether its possible to do this in a timely fashion.
Bill: This seems ambitious, it doesn't seem like a group as large as this can make timely progress.
Kurt: Point well taken, we need to consider what sort of process could make this happen effectively.
Mark: We could have an implementation in a couple months. I'm working on the spec, and if I continue working on it myself, I can perhaps have something in a couple months.
Kevin R.: Sun is working with SGI, Intel, and Apple to define Java3D. Hope to have a spec in early Jan. Will go for public review after review by partners.
Mark: Fields and routes are in VRML 2.0 but not in the current Java3D spec.
Kevin R.: Part of our desire to get the spec out early in '97 is to resolve issues on how Java3D and Cosmo3D are related.
Steve W.: I know of at least a couple of vendors that are attempting to develop products like this. This doesn't say that we shouldn't go ahead, but it could be a significant barrier.
Straw poll: Which ARB companies would like to see the ARB control the spec for a scene graph library? Let's assume that the licensing terms are attractive. Seven. Who's confident they will not vote for it? One. And one abstention.
General feeling around to see how to proceed.
Actions:
Initial email discussions will be conducted over the opengl-arbgoers list. Paula will send out the current opengl-arbgoers mailing list so people can see who's on it.
Bimal passed out a diagram containing his revisions to Fig. 2.7. One change was suggested, and the vote to replace the current Fig. 2.7 with Bimal's revised version passes 9-0-0.
The following change to the discussion of display lists was proposed and passed by a vote of 9-0-0. In Sec. 5.4 under the discussion of the EndList command, the following text replaces the text that starts with, "In this case GL implementations of revision 1.1 or greater..." and ends with "(It is as if no attempt had been made to create the new display list.)":
In this case GL implementations of revision 1.1 or greater insure that no change is made to the previous contents of the display list, if any, and no other change is made to the GL state, except for the state changed by execution of GL commands when the display list mode is COMPILE_AND_EXECUTE. (The remaining parenthetical statement is deleted.)
Future meetings:
Paula passed out specs for two GLU extensions EXT_nurbs_tessellator and EXT_object_space_tess. Both of these have already been implemented and will be in the upcoming sampleGL release. People were asked to review the specs and comment.
Paula discussed some of Andy Vesper's comments on the NURBS tessellator extension. For completeness, we should support GLU_OUTLINE_PATCH.
We agreed to make the following changes to the implementation and specification of these extensions:
These changes will delay the release of sampleGL. Paula agreed to post a schedule. None of the ARB members had a problem with the delay except IBM who needs the man pages right away.
Once sampleGL is available, licensees should review all three of the new GLU extensions with an eye towards incorporating them in a GLU 1.3
A beta version of Cosmo OpenGL (software implementation of OpenGL for Windows95) was released to a small number of sites last week. The beta test period will be approximately six weeks. Cosmo OpenGL is its own DLL ‹ it's not done as an MCD or ICD. Any OpenGL licensees that are interested in the source for Cosmo OpenGL should contact John.
![[SGI Surf home]](/Images/Icon/surf.gif){kind=icon}
![[Dev. Program]](/Images/Icon/extreme_icon.gif){kind=icon}
Copyright © 1994, 1995 Silicon Graphics, Inc. All Rights Reserved. Trademark Information