ARB Meeting
Notes ARB Meeting
NotesHosted by Real3D in Orlando, FL
Meeting notes taken by Randi Rost, HP
| Dale Kirkland | Intergraph | 205-730-6085 | kirkland@ingr.com |
| Randi Rost | HP | 970-229-2447 | rost@fc.hp.com |
| Kevin Lefebvre | HP | 970-229-4382 | kevinl@fc.hp.com |
| Jon Brewster | HP | jon@cv.hp.com | |
| Bill Sweeney | Sun | 415-336-5147 | sweeney@eng.sun.com |
| Henri Warren | DEC | 619-618-7145 | warren@rbc.dec.com |
| Igor Sinyak | Intel | 408-765-5839 | Igor_Sinyak@ccm.sc.intel.com |
| Pat Brown | IBM | 512-838-0368 | pbrown@austin.ibm.com |
| John Schimpf | SGI | jsch@asd.sgi.com | |
| Jeremy Morris | 3Dlabs | 44-1784-476641 | jeremy.morris@3Dlabs.com |
| Drew Bliss | Microsoft | 206-936-7564 | drewb@microsoft.com |
| Kurt Akeley | SGI | kurt@sgi.com | |
| Otto Berkes | Microsoft | 206-936-9563 | ottob@microsoft.com |
| Bimal Poddar | IBM | 512-838-0492 | poddar@austin.ibm.com |
| Bill Armstrong | Evans & Sutherland | 801-588-7975 | armstron@es.com |
| Bill Clifford | Digital | 603-881-2268 508-493-6420 |
clifford@bgsdev.zko.dec.com |
| Dick Jay | Template Graphics Software | 619-457-5359 x236 |
jay@tgs.com |
| William Newhall | Real3D | newhallw@real3d.com | |
| Richard S. Wright, Jr. | Real3D | 407-306-3054 | wrightr@real3d.com |
| Tim Kelley | Real3D | kelleyt@real3d.com | |
| Hanspeter Pfister | MERL | 617-621-7566 | pfister@merl.com |
| Rob Putney | IBM | 512-838-3639 | rputney@austin.ibm.com |
| Fred Fisher | AccelGraphics | 408-467-5018 | agi-arb@ag3d.com |
| Kartik Venkataraman | Intel | 408-765-0006 | kvenkat@gomez.sc.intel.com |
| Daniel Daum | AccelGraphics | 408-467-5008 | danield@ag3d.com |
| Paula Womack | >SGI | 415-933-1946 | womack@sgi.com |
| Michael Jones | SGI | mtj@sgi.com | |
| David Blythe | SGI | blythe@sgi.com | |
| Steve Wright | Microsoft | swright@microsoft.com | |
| Peter Doyle | Intel | 916-356-0969 | Peter_Doyle@ccm.fm.intel.com |
| Gene Munce | Intel | gene_munce@ccm.sc.intel.com | |
| Jim Hurley | Intel | Jim_Hurley@ccm11.sc.intel.com | |
| Kevin Rushforth | Sun | kcr@eng.sun.com | |
| Mark Segal | SGI | 415-933-1385 | segal@sgi.com |
The handouts in the list below were distributed at the meeting. If the the document title is not linked to the actual document, you can request a copy of the document from the contact person listed.
After a round of introductions, SGI passed out copies of the newly released Blue Book. The release of the new version of the Red Book is imminent, but SGI had not received copies prior to the meeting.
Following the same process that was used for OpenGL 1.1, the group launched into a discussion of what should be considered for inclusion in OpenGL 1.2. SGI proposed that the packed pixels and texture3D extensions be added to OpenGL 1.2. No one other than SGI had interest in the interlace extension. The palletted (prefiltered) texture table and the postfilter texture table were also proposed. There was some interest in adding the texture LOD and texture LOD bias. Several people were also interested in adding the texture border clamp and texture edge clamp extensions. Kurt proposed considering an extension that includes BeginScene/EndScene semantics. This could be used to support tiled renderers. Following is the complete list of capabilities that were considered:
At the previous meeting, there was general support for defining a set of imaging capabilities that would be an optional part of OpenGL 1.2. The following list of extensions were considered for inclusion in the optional imaging module:
The group also identified the following list of extensions that were considered for inclusion in the next version of GLX (GLX 1.3):
Next, the group attempted to define a set of criteria that could be used to help decide what to add to OpenGL V1.2:
General feeling was that we should be revving the spec every 1-2 years. The discussion turned once again to whether there was a need for an ARB approval process for common extensions. One suggestion was to define ARB-approved extensions. Once defined as an ARB-approved extension, the spec would not change (other than in upward compatible ways as the OpenGL core spec changes). The downside is that you wouldn't be able to rev these extensions outside of the normal OpenGL core spec revsions.
The first alternative discussed was to have a single document defining OpenGL that had some optional capabilities (like imaging). The entire spec would rev from 1.n to 1.n+1. The second alternative discussed was to have separate documents for core OpenGL and for the optional capabilities. The optional capabilities could be revved independently of core OpenGL.
Straw polls for inclusion in OpenGL V1.2 (one vote per company present - total of 14 companies represented):
The group also conducted straw polls for inclusion of various imaging extensions in the "optional imaging capabilities" bucket. There were nine organization voting on these extensions: HP, Sun, SGI, DEC, IBM, Intel, MERL, Intergraph, and 3Dlabs.
Mark Segal gave a presentation to motivate the need for a higher-level toolkit library
Slide #1: Why a higher-level API?
Slide #2: What's the right level?
Slide #3: Why the OpenGL ARB?
Dick Jay: We think that the OpenGL ARB is very good at what the ARB does. A scene graph API is a large undertaking, and we would hate to see the ARB's current work "diluted" by such a new effort.
John S.: It's not necessarily the case that we would dedicate a large portion of the ARB agenda to this. There may be another group with significant overlap in membership with this group that meets to discuss the detailed issues. Perhaps there's only a subcommittee report at each meeting.
Kurt: We need to learn to work smarter and be more organized. We could come to meetings more prepared, have subcommittees, delegate, etc.
Jon: There are three different approaches that are possible, (A) codifying existing efforts, (B) creating something from scratch, or (C) creating something from competing efforts. The group needs to decide which to pursue.
Igor: It's not that clear that we could do a good job at the scene graph level since most people here are hardware/system vendors.
Micheal: The reason to embark on a standards effort is that everyone who participates thinks they will benefit in some material way by the results of standardization. There are lots of opportunities to provide optimization value with a scene graph API that aren't available in OpenGL.
Steve: A scene graph API requires a lot more ISV input than the OpenGL API level.
Dick: I really think that this group only has a part of the membership needed to be successful at the scene graph level. We need a lot more input and representation from the user community.
Paula: But we all work with ISVs and get input from them on an ongoing basis.
Steve: The difference between this and the original OpenGL effort is that no ISV's were doing rasterization on their own when OpenGL came along, but there are a lot of ISV's who have been doing their own scene graph code.
Paula: Do we really need direct involvement of the ISV's? I don't think so. We just need to get their requirements.
Steve: I'd like to get at least a first round of requirements input from ISV's.
Slide #4: OpenGL++ must...
Bill A.: This also needs to play in the world of the Internet. This could include supporting common file formats, level of detail, just-in-time polygon delivery, etc.
Steve: How many people are already shipping products that address some of these requirements? We need to develop a good migration story for the customers of these existing products.
Jon: There is rich set of things that can be addressed by a scene graph API. Therefore there is a rich solution space, and vendors are poised to deliver a variety of solutions. It will be difficult to go deep into a discussion of the requirements because each vendor will have customer requirements that might only be discussed under non-disclosure.
Mark: I hope that we can distill the requirements without the need to look at every application or market-specific toolkit that could be built on top.
Steve: I've talked to vendors recently who have said,"You know, we're already doing that stuff and we think we can do it better than any general purpose vendor." I think we really need to understand what these folks are doing.
Drew: Which language bindings are important? C++ and Java might be sufficient, but does anyone want support for any other languages? Perhaps a more language-independent object model should be developed.
Slide #5: OpenGL++ must not...
Slide #6: Required Features
Slide #7: Schedule
Fred: How confident are you of making this schedule?
Mark: It's aggressive but doable if we manage what we consider for the first version.
Bill A.:Is there a point at which this is so late that it's no longer interesting?
Michael: It will always be interesting, but if we can move quickly, we can have a single solution that everyone supports. It's so interesting that in a year, people will have their own ways to solve this problem and the market will be faced with a bunch of incompatible solutions to the same problem.
Slide #8: OpenGL++
During the course of the discussion, the following list of scene graph issues was developed:
John S.: Are we at the point where we can decide whether we can agree to move forward on this?
Steve: How does this relate to Cosmo3D?
Mark: Cosmo3D started out being a VRML toolkit. We think we need to get some of the VRML stuff out and add some other stuff, since we want to do a lot more than VRML in OpenGL++.
Bill A.: How does the Cosmo3D implementation fit in?
Mark: I've told the development team that we'll be throwing away the Cosmo3D implementatoin and starting over. But from a practical standpoint, we'll leverage the code as much as we can.
Kurt: SGI believes that we have to move forward in this area, and we are moving forward. We're willing to change what we have in order to make it acceptable to other companies, but we're moving ahead regardless because we believe that this is the right way to go.
Michael: It's not "Unity or failure", but "Unity or something else that isn't quite as good."
Steve: Each of us who already has an investment in this area has to consider how much we are willing to modify, integrate, or rework in order to take advantage of the opportunity to cooperate on a standard.
Kevin R.: I'm concerned about the issue of extensibility vs. performance, and about how "OpenGL-centric" this effort should be. Should "reaching around" this library to OpenGL be a goal?
Michael: I believe this level should be very OpenGL-centric. I also think it's critical to allow applications to"reach around" and access OpenGL. It can be quite frustrating for an application to be locked into access through a higher-level API with no way to do things that the underlying layer could accomplish.
Hanspeter: Can you comment on the breadth you are attempting to address? You say you want to support audio rendering, but audio rendering can have very different requirements than visual rendering. I've also seen people wanting to do haptic rendering. Will you consider all of this?
Mark: We need to bite off a limited set of things at first, and try to build a framework that could incorporate new things over time.
Questions/Concerns:
Steve: We have a dilemma in our environment. We've added a triangle interface to Direct3D in order to improve the compatibility with our OpenGL. But all of the audio and video support in our environment comes from the ActiveAnimation side of our environment. If we are too OpenGL-centric with this effort, it seems like it would drive a wedge between our ActiveX and OpenGL efforts at a time when we're looking ways to tie them more closely together.
A straw poll of the organizations present was conducted in order to determine the level of interest in moving ahead with this proposal as an ARB activity:
IBM (Bimal): We're definitely interested in pursuing this.
Intergraph (Dale): We think this is a good thing. We have an issue with some ongoing work. I think this is the right body to work on it. We're for it, just need to figure out how to merge it into our business plans.
AccelGraphics (Fred): We'd like to see the effort proceed. This is the right group. We'd like to make sure the various goals are met, e.g., working out the issues with ActiveAnimation.
Microsoft (Steve): We have some dilemmas. How it relates to ActiveAnimation, other APIs, and to ongoing efforts with some partners. We do want to support a standard in this area. We have to learn from our ISVs. We need to talk over things back at the office before we can decide.
3Dlabs (Jeremy): We support this. We've been looking for something to solve some of the problems that this addresses. This kind of effort will help promote/enable applications.
Real3D (Richard): We think it's a good idea to support a low-level scene graph API as long as it isn't too thick. We believe in making this library OpenGL-specific. We like the idea of having an ARB-sanctioned standard in this area. A low-level standard would benefit new application development.
HP (Jon): We really do care about this area. There's a lot of opportunity for adding value in this middleware area. We need some time for internal discussions before we can say yes or no. We have multiple support issues to consider including support across workstations and PC's.
DEC (Bill C.): We're less concerned about having something in six months than in getting the right answer. We like the direction of the OpenGL++ layer heading towards something lower level than we first envisioned. The work needs to be done close to the ARB. We're concerned about whether the bylaws as currently written allow us to work on things other than OpenGL. We think that the ARB needs to continue to develop OpenGL to support things that are needed by libraries like OpenGL++. Need some time to go back and have some internal discussions.
Intel (Igor): We're very much committed to having a standard scene graph API. We're committed to Java3D. We're not ready to say this has to be OpenGL or nothing. This might not be the right group to develop this. We're concerned about making the API flexible enough to address all of the things we'd like to do. More time would help in order to work things out internally.
MERL (Hanspeter): An open standard is something we would welcome. My concern is on the architectural level: could all of the kind of things that we do fit into the framework of OpenGL++? We'd like to contribute to this effort if we can. (Big multiuser systems, volume rendering, haptic rendering)
TGS (Dick): I need to talk to my bosses and such. We still have the concern about the workload for the ARB. If the ARB is going to take this on, it will have to organize itself so that the current work and this new work can be supported. I think an API at this level is useful, particularly if it is a thin layer like we've discussed. It's not the next Inventor, it's the thing that will be used to build the next Inventor, and that's nice because it leaves us something to do.
E&S (Bill): We have some technology in Integrator, but do not view this as a competitor. The scene graph capabilities are only part of what Integrator does. We're not intending to push our technology for anything more than solving our problems. We'd like to be involved...our commitment would vary depending on the success we foresee.
Sun (Kevin R.): We are focusing our efforts on something other than what's been proposed here - Java3D. We're about ready to release a spec. We're not neccessarily interested in pursuing an OpenGL++ effort right now, since it will be a distraction to our Java3D effort. Don't mistake that for lack of interest though, if the ARB moves forward, we'll participate.
SGI (Kurt): We're excited to move forward. It's exciting to hear the level of support for this effort.
Some folks need to go back and engage in discussions about whether this makes sense for their business. Others want to move ahead with technical comment and discussion of goals.
John S. takes the action item to answer the question about whether the bylaws permit the ARB to work on a new spec such as this.
Rob: Could Microsoft, HP, Sun, or anyone else contribute an alternative solution that would meet these goals?
Kevin R.: I could commit to finding out whether we're prepared to offer Java3D as a solution.
Jon: HP can check into what's possible to offer.
Igor: We have a proposal to contribute.
Kurt: SGI is prepared to offer up technology unconditionally. We understand that we lose control when it is given to the ARB. Other vendors should make it clear what strings (if any) are attached when they offer up technology. For instance, the ARB needs to know whether the technology must be taken as is or if it can be used as the starting point to develop whatever the ARB thinks is the right solution.
Bill C.: Does SGI intend to charge additional licensing fees for this?
Kurt: The trend in our licensing is downward. We're not attempting to make an income on this stuff.
John S.: Licensees shouldn't expect to have to pay anything more for this stuff.
Michael: If we do a sample implementation and have an engineer or two supporting it all the time, then it would seem to be reasonable to have a maintenance/support fee.
Is there anyone in the room who does not want to take a vote on March 7th on whether the ARB should move forward on developing a scene graph API? No.
David passed out a couple of extension specs and led a discussion about them. The per-fragment lighting extension defines a way to apply lighting effects to fragments. This is orthogonal to the per-vertex lighting already defined by OpenGL. This extension defines a new set of lights and material properties that are applied to fragments after texturing has occurred. The normal at each fragment is derived from the current vertex normal. David has left this deliberately vague in order to get feedback on what schemes people would like to see for normal interpolation. Kurt suggested that it would be good to allow the mode where the normal isn't interpolated at all.
The multitexture spec defines a way to apply more than one texture to a fragment. David drew a simple diagram in this spec with an assumption of four simultaneous textures. Two didn't seem to be sufficient for this analysis, but the actual number of simultaneous textures would be an implementation decision. Texture environments are cascaded.
Drew stated that Microsoft has been working on similar ideas. The biggest difference is that there is a separate "texture combine" function that can be specified. This maps on to the capabilities of one of the PC graphics cards they've seen (3Dfx). Drew then passed out the EXT_multiple_textures spec that they've developed. There were a lot of similarities between the SGI proposal and the Microsoft proposal. The two companies will try and work out the differences in the proposals. Microsoft would like to see a jointly supported multiple texture proposal solidified within the next two months.
Straw votes were conducted to determine support for the following extensions. Seven companies were voting on GLX support issues.
There is a sentence on p. 46 of the spec that says, "Results of lighting are undefined if the wew in eye coordinates) of V
Paula presented a proposed schedule if we really want to get out a new spec in a year.
Should this be in the core for OpenGL 1.2? (ARB members only, for/against/abstain)
Bill A. developed a table to lead the discussion of per fragment lighting:
| C1 | T(C2) | |
| Standard OpenGL | 0 | Final Color (E) |
| "Lit" Texture | e+s | A+D |
| Reflection Mapping | Final Color | S |
| Emissive Texture | Final Color + Emmisive | 1 (or replace) |
| Phong Texture | Final Color - S | S |
| Bump Map (fragment) |
Who wants to see specular lighting after texture? (9/0/0) The API should consist of an enable bit and the default behavior. There was some discussion about whether the default behavior should include the contribution from the emissive component (some existing hardware does not support a contribution from the emissive component). Bill will own the spec and issues for this extension.
Paula will take ownership for packed pixels, texture3D, texture LOD, and texture edge clamp. Drew will take prefiltered texture lookup table, range elements, lock/unlock vertex arrays. Bimal will own the rescale normal extension.
Are there any ARB members who would vote against the 1.2 spec if any of these extensions? Microsoft is not sure that texture 3D would be too useful in a software product. PC graphics vendors (Intergraph, Real3D) responded that they planned to produce hardware products to support this.
Some folks think that there doesn't seem to be a compelling set of capabilites for OpenGL 1.2. Others respond that the support for specular highlights on textures will fix a big issue.
Randi drove the discussion of which extensions should be included in the optional imaging module and will own the issues list (ARB members only, for/against/abstain):
Paula drove the discussion of which extensions should be included in GLX 1.3 (ARB members only, for/against/abstain):
Make current read was discussed some more. This extension (or something like it) is required to get the contents of the pbuffer onto the screen. Revote: (6/1/2). Paula will own the issues list for the GLX stuff.
SGI will create a new mailing list that contains the union of opengl-licensees and opengl-arbgoer.
New sample implementation release should be available next week.
SGI has gone ahead and put out a proposal for Java bindings for OpenGL. They have been unable to get the necessary changes to AWT, so they're proposing adding the following new bindings:
public DrawConfig(component target, Object arg);
public CanvasEXT(DrawConfig arg);
public Synchronized void swapBuffers();
public OpenGLContext(DrawConfig drawConfig)
public OpenGL(OpenGLContext context, CanvasEXT canvas);
SGI is planning to put this out on the web site for people to look at. It will be labeled "preliminary" but it would be useful for people to see this and be thinking about it. Sun is working on a proposal for AWT and will mail it out when it is ready.