ARB Meeting
Notes ARB Meeting
NotesHosted by Hewlett-Packard in Boulder, CO
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 |
| Doug Twillenger | Sun | Doug.Twillenger@sun.com |
| William Sweeney | Sun | william.sweeney@sun.com |
| Henri Warren | Megatek | warren@megatek.com |
| Igor Sinyak | Intel | Igor_Sinyak@ccm.sc.intel.com |
| Pat Brown | IBM | pbrown@austin.ibm.com |
| John Schimpf | SGI | jsch@asd.sgi.com |
| Jeremy Morris | 3Dlabs | jeremy.morris@3Dlabs.com |
| Jim Cobb | Parametric Technology | jcobb@ptc.com |
| Ken Garnett | NCD | keg@ncd.com |
| Steve Wright | Microsoft | swright@microsoft.com |
| Kurt Akeley | SGI | kurt@sgi.com |
| Otto Berkes | Microsoft | ottob@microsoft.com |
| Bimal Poddar | IBM | poddar@austin.ibm.com |
| Bill Armstrong | E & S | armstron@es.com |
| Craig Dunwoody | SGI | dunwoody@sgi.com |
| Bill Clifford | Digital | clifford@bgsdev.zko.dec.com |
John Schimpf thanked all the vendors who participated in the OpenGL technology area at the SGI booth at SIGGRAPH. He noted that Sun has announced a product that supports OpenGL (Creator 3D) and that HP was doing a technology demo of OpenGL in their booth. This increased industry support is good news for the OpenGL effort.
The second half of Mason's book will be sent to reviewers in a couple of weeks. He will begin applying comments on the first half while the second half is under review. The schedule calls for the book to be released by the end of the year. The "green book" (Mark Kilgard's book on OpenGL and X) is available. Galleys of the "OpenGL and Windows" book were on display at the show and the book should be available in a few weeks.
Kurt stated that he was pleasantly surprised by the prevalence of OpenGL at SIGGRAPH. He thought there might be more emphasis on Direct3D or Talisman. Dale agreed, saying that he thought Direct3D would kind of be "beneath" SIGGRAPH but would be more prevalent at COMDEX or shows like that. He talked to a couple of people about imaging and didn't get much consensus with these two point samples. He's heard people asking for Porter/Duff blending and for more/better support for video.
Randi stated that he's talked to customers who want to do imaging with a standard API. OpenGL goes a long way towards providing the image display capabilities that are needed by traditional imaging applications. The imaging extensions developed by SGI take care of most of the remaining image display requirements. The class of imaging operations that are unique to a particular image application or acquisition system are left to the application to perform on the CPU. The appeal of OpenGL to ISVs is that as their application requirements expand, they have the ability to merge geomety, imaging, and volume rendering capabilities in a straightforward manner. It seems like some traditional "imaging-only" companies are poised to take a big step up in their visualization capabilities by adding geometry and/or volume rendering techniques to their imaging applications.
Dale: Are imaging algorithms "stable"? Kurt: yes, some are. We also need to lead in some respects. We shouldn't be too cautious. He mentioned the image caching paper at SIGGRAPH and Talisman as uses for imaging.
Are anyone besides HP and SGI doing the imaging extensions? Intergraph feels the pressure. Sun has "agreed to disagree" because their current generation of hardware does not contain hardware texturing support. IBM does not currently have a large presence in the imaging market and is looking for ISV interest in the imaging API extensions before investing its efforts in this area. DEC has concentrated on getting 1.0 and 1.1 stuff out the door.
What should we do to keep moving the standard forward. Otto says that we could move up the chain and address the object-oriented levels above. Jim C. says that there are some things that are hard in a layered environment (e.g., NURBS). Igor is interested in addressing the inadequacies for character animation, for instance a transformation per vertex rather than per primitive. Jim C. has heard a requirement for annotation text or screen-aligned stroke text. The rescale normal extension would be supported for OpenGL V1.2 by SGI, Microsoft, IBM, and E&S. Bimal has heard a requirement for light sources with non-zero area (e.g., fluorescent bar lights). Several folks (Microsoft, E&S) are interested in an extension to support specular highlights on textures. Kurt mentions that a way to support multiple simultaneous textures might also be interesting.
Randi mentions that it would be useful to have a level of standardization that falls between putting something into OpenGL itself and the current mechanism for EXT extensions. We described the possible "levels of agreement" between vendors as follows:
The first level describes the case where a vendor defines an extension that is unique to that vendor's platform. The second level describes the current EXT mechanism, which promotes informal agreement between vendors on common extensions. The informal agreement at this level can cause problems with compatibility between vendors, particularly as the spec evolves. Kurt agreed to think about a process for the heretofore nonexistent third level, which would allow vendors to cooperate on a set of extensions on equal footing with formal agreement and mechanisms for ensuring compatibility between vendors.
Could we do conformance tests for EXT extensions? Yes, this level of branding is still helpful. The real test for compatibility is ISVs porting their code. There hasn't been much interest in the conformance test results, so we think nobody cares about the results.
Several vendors would like to see more conformance tests. Kurt thinks that the group's attitude about conformance tests has "loosened" in that it would be easier to get the group's approval. Dale would like to see a "shared Q/A" where more tests are contributed but the results would not be reported.
Should EXT extensions be described in an appendix in the Addison-Wesley books? No, the consensus is that the process of defining an EXT extension is not rigorous enough. Kurt takes this as an action to work to develop a more formal process for achieving "blessed" extensions.
Kurt: should the ARB have its own web site? Might be a good idea for publishing extension specs, meeting notes, etc. There was general agreement that it would be a good thing to have an ARB controlled web site that is separate from SGI. John will start the ball rolling by organizing the current web site. People from each company should look at it and tell him what needs to be added/changed/removed. Randi and Bill Sweeney offered to help, and Bimal will check to see if someone at IBM can participate. Kurt thinks that it would be the "right thing" to pay a third-party to develop and maintain the site.
John: Do people want to have more of a marketing focus on OpenGL? Getting stuff ready for SIGGRAPH was like pulling teeth. It might be good to have a marketing committee that maintains a web site and does other basic marketing things. Perhaps our group could do this work...the web site seems like it could contain mostly technical material. John would like to see pointers to OpenGL applications on the web site. Jim wants to see the latest specs on the web page. He does not have access to the email list where announcements of spec revisions are made.
Should we give out the source to the conformance tests? We were sensitive to this previously, for instance to differentiate "Official" OpenGL implementations from something like Mesa. Microsoft would like to publish the source for the conformance tests on their DDK. These could also be made available through the ARB's web site. Could there be a registration/validation process for ISVs and IHVs?
Kurt thinks that it's time to add more imaging to OpenGL and stated this at SIGGRAPH. He would consider creative ways of doing things so that we could keep moving forward with the standard rather than be stopped by the inertia of the size of OpenGL currently. (Much of the preceding conversation also related to this topic.)
What is the process for "blessing" the man pages for publication in the second edition of the blue book? Does the ARB vote on the man pages? The recollection is that the ARB hasn't voted on man pages before. Bimal thinks the ARB should "bless" the man pages with a formal vote if they get published with the ARB's name. It was agreed to discuss the issues that people have identified already and then have a review period of three weeks followed by an email approval vote.
Jim states that the currently specified behavior for spotlight transformation is incorrect if the modelview matrix includes a skew. Jim proposes that we change the definition of spotlight to say that the spotlight direction is transformed by the upper 3×3 portion of the modelview matrix rather than the inverse transpose of the modelview matrix. Jim will develop a proposal for changing the spec and an ARB vote will be conducted via email. A "direction" should not be treated the same way as a "normal".
In the glXMakeCurrent man page, it says that a BadCurrentWindow error will be generated if the window has been deleted. Bill S. proposes deleting this sentence. He will write up a proposal and send it to Kurt, who will mail it out for a vote.
The man page for glXGetConfig is inconsistent with the spec in that it specifies that both RGBA and color index must be supported (the spec says that color index must be supported if a color index visual is supported). (Was any action taken on this issue???)
Dale has a bunch of handwritten edits to the man pages that he will turn over to SGI. We discussed those that were more significant than typos or nits.
Dale will write up the non-trivial comments so that they may be seen by all.
Kurt: don't worry about formatting stuff - the publisher will look out for that.
Kurt proposes that we don't talk about the initial values for attributes that are essentially pointers, since there is nothing useful that you can do with the initial value (NULL).
Jim C: passed out a proposal for changing the spotlight definition. Kurt will send the proposal out for an email vote.
Some of us have always wondered why Kurt says "vertexes" and "indexes" while the rest of the graphics world says "vertices" and "indices". There is a reason. Dictionaries list the preferred plural form first if there is more than one acceptable plural. "Vertexes" and "indexes" are listed first in all the dictionaries Kurt has looked at. "If you let them read vertices long enough, damned if pretty soon some people won't start asking for a vertice," he says. However, he also notes that "matrices" is still listed before matrixes.
Kurt passed out a handwritten handout containing the spec clarifications to be discussed at this meeting. These were dispatched as follows:.
SGI felt it was necessary to do an implementation of OpenGL on a PC platform in order to prove that OpenGL could indeed run well on "generic PC" - a Windows 95 platform with floating point. They have been working on an implementation intended to run well on platforms without hardware acceleration. At SIGGRAPH, SGI promised to make this implementation available on their website for anyone to download. SGI's motivation is to make sure OpenGL is successful on a wide range of platforms. This is not a business opportunity for SGI per se, but a long-term strategic action to make sure OpenGL is successful.
Otto: SGI is creating a perception problem for us - we provide a fast implementation for unaccelerated platforms too. I think it would be better for OpenGL if you provided compelling applications.
John S.: Cosmo 3D is the compelling application, and we need the underlying layer to perform well, even on unaccelerated platforms. Also, we've heard Microsoft say that their emphasis was on OpenGL for hardware accelerated platforms.
Otto: If that were true, our software only viewperf numbers wouldn't look as good as they do. We've put a lot of effort into our software OpenGL implementation.
Kurt: We did not hear strong support for OpenGL through Microsoft's marketing messages.
Steve W.: We've had to be politically correct. The growing acceptance of NT is helping us with our OpenGL story.
Steve W.: OpenGL for Windows is available through our ftp site and through OSR2.
Steve W.: All the hardware we're seeing coming for the next year or so is RGB at 16 bits or higher. Color index mode is becoming a dinosaur.
John S.: I encountered a number of vendors who were considering doing a port to Direct3D. I'd like these people to know that OpenGL is a viable alternative.
Steve W. If you can let me know who these people are, I'd like to do some focused evangelism for OpenGL.
Steve W.: When SGI gets viewperf numbers, we should talk. If yours are better than ours for some things, we'd be interested in understanding why.
Kurt: and vice versa.
Otto: We'd hate to have applications see any performance decrease.
Kurt: We're trying to fill in what we perceived was the largest void - an implementation that kicks ass for simple drawing.
Otto: Another issue is quality, we've spent a LOT of time building our OpenGL. Also, there is an issue with supporting IHVs. If SGI releases this stuff, vendors would have to write multiple drivers.
Kurt: Would it make sense to get our folks together to compare notes on performance and whatever else?
Otto: Sure. (John S. will coordinate the meeting).
Kurt passed out copies of the OpenGL extensions that they think are useful for supporting Cosmo 3D.
Vertex cull: Vendors may choose to implement this extension on highly accelerated devices by doing nothing. Also, applications should only use this if there is a lot in a scene that should be culled. If the scene contains nothing to be culled, this extension is a time waster. This extension is done for performance - just to save transformation computations.
Compiled Vertex Array: Is there a need for an array of pointers call? Some people have thought of doing this. It would save some procedure calls and guarantee atomicity for the drawing command.
The next meeting was tentatively scheduled for the week of Dec. 2 in San Diego. If we met this week, it would have to be in the suburbs somewhere due to hotel availability. If held the following week, it could be in San Diego. A couple folks have other conflicts the second week, so the group consensus is to meet on the first week, on Monday and Tuesday. (Later discussion: conflicts are resolved, so group consensus is to express a preference for the second week.)
See the handout on conformance test changes The three conformance issues are:
The fixes to these three conformance test issues were approved together by a vote of 7-0-0. Pat then brought up another conformance test issue where the code incorrectly assumes that the number of bits in the depth buffer is greater than zero, e.g.:
spop.c
glDepthFunc(GL_NEVER)
trueValue=Setup(ALWAYS, ZERO);
value=Test(KEEP, ZERO, KEEP);
if (trueValue != value)
{
fail;
}
The proposal is to put an if test around this block of code in each of the six or seven tests in which it occurs, to make sure the number of depth bits is greater than or equal to 1.
Passes 7-0-0. Pat will provide the changed code to Kurt.
An IBM customer reported tessellation errors and some extreme over tessellation in certain cases. IBM understands that SGI has fixed the code and wants to know when licensees will get the code. SGI has used the fixed code in other SGI products and it was a major rework, so there is some reluctance to release it to OpenGL licensees. Craig and Kurt believe that the new NURBS code also requires API changes, so a rev of the GLU spec would be required to release this code. Kurt will figure out what to do and let us know.
The GLU API for gluBuildMipmap and gluScaleMipmap should take intensity and alpha formats.
The GPC folks came up with a schedule for meetings in 1997.
Randi described HP's Voxelator CD-ROM and gave out copies to those who hadn't yet received one. This CD-ROM was HP's effort to publicize volume rendering technology and get feedback from the industry on the best way of supporting volume rendering in the OpenGL environment. Since several people involved in volume rendering had expressed dissatisfaction with the use of 3D texture mapping for volume rendering applications, HP decided to develop and publicize an alternate set of extensions that support volume rendering in a more direct way. This is done by defining a new pipeline for OpenGL, one that accepts voxels directly and outputs fragments just like the geometry and pixel pipelines. The voxel pipeline has been defined to provide interactive support for volume rendering capabilities like gradient computation and classification. The CD-ROM contains a spec and man pages for the new routines and prototype implementations for HP workstations as well as PC platforms. The online version of this information can be found at http://www.hp.com/info/voxelator A feedback form is included so that people can comment on the spec. A large number of technical papers on volume rendering were republished on this CD-ROM, and portions of web sites dealing with volume rendering were also reproduced on the CD.
Igor: Intel would like to see OpenGL become more friendly to character animation. In order to support smooth character motion, it would be nice to have a separate transformation for each vertex.Have others thought about this problem? Could it be supported with an extension?
Henri: What about Push/Pop matrix?
Otto: Can you think about this as an extension to vertex arrays?
Kurt: We considered naming the top "n" matrixes on the matrix stack and allowing you to specify within a Begin/End which matrix you intend to use.
Bill A: This seems kludgy.
Kurt: We didn't do it.
Bill A.: Perhaps define a different type of Begin that would allow the matrix modification within the Begin/End.
Pat: Seems like what we're doing is moving something that could be considered a preprocessing step down into OpenGL.
Kurt: The reason we backed away from this is that we didn't think that people actually solve the problem by having a matrix per vertex. We found that people solved the problem by creating an n-dimensional distortion field.
Igor: Disney also wanted to have two transforms per vertex and have a way of weighting the contribution of each.
Kurt and Pat expressed interest in working with Igor on an extension definition.
Bill A.: What about caching and naming the affected vertices?
John: Cosmo 3D does not include Cosmo OpenGL. It will use the resident OpenGL.
John: SGI has been working on merging Inventor and Performer. Cosmo 3D is a subset of this merged API that will be released in the future. It reads and writes VRML 2.0 files and renders using OpenGL. SGI has brought these ideas to the Java3D discussions. SGI is saying that Cosmo 3D is a Java 3D implementation. One of the things that is still being worked out is how the Cosmo 3D architecture will be evolved. Another is how SGI would provide a sample implementation or other assistance to other vendors. Cosmo 3D does not depend on any proprietary extensions. It runs on top of standard OpenGL. SGI also has a 3D browser plug-in called Cosmo player.
Otto: Replacing Microsoft OpenGL is essentially replacing a system component of our OS which is not a good thing. We would not support systems in which one of our DLLs has been overwritten.
Jim: Is the spec available?
John: The current spec is a little out of date. I'll try to get an up-to-date spec to people within a few days.
Craig: The changes needed to the standard Java run-time environment in order to get awt to set up an OpenGL-capable window have been proposed to Sun by SGI but so far nothing has happened.
John: Can we get Sun to increase the priority of this?
Bill W: The small team working on Java has been overwhelmed. They're doing prioritization and load balancing.
Kurt: The OpenGL Java API is clearly a second priority to Java 3D. Java 3D contains the heavier-weight rendering so as to amortize the overhead of rendering calls in the Java environment. But it still makes sense to provide the OpenGL API so that you could "reach around" and accomplish things that aren't possible with Java3D. The choice for the binding is essentially the same that we had for the Ada binding. We are currently proposing doing it the lightweight way; the Java folks would prefer the "heavyweight" approach where everything was done with native methods.
Craig: last meeting we set a goal of voting on adding GLS as a standard at the December '96 meeting. (Brief intro of GLS). GLS was first presented at the Dec. '94 meeting. The idea was that GLS would be an optional part of the OpenGL environment. Companies are expected to ship GLS when they have a compelling reason to do so. First half of '95 was spent working with Drew Bliss at Microsoft to make sure the implementation did what was required for Microsoft.
GLS REF 1 went out with the OpenGL 1.1.0 sample GL release. At the May '96 ARB meeting, it was decided to have a comment period until June 15. Some comments were received from Bimal. If you haven't looked at the spec yet, please do so. At the May meeting, we set the goal of voting on the spec at the December meeting. I'd like to have a "final" spec available by the end of September. This would be the version of the spec that we'd vote on.
We had talked about a public review period. Do people think that this is worthwhile? If so, how do we do it?
Bimal: Have we shared this with any ISVs? We could post this to the newsgroup, but not all ISVs read the newsgroup. I'm not sure we've gotten enough stuff built on top of GLS to know for sure that it's correct.
HP and SGI think that GLS as defined can be used to build a print solution. Microsoft used a previous version to build a print solution.
Kevin: What's currently in GLS is necessary. There are some things that still may need to be done: e.g., support for using printer fonts rather than bitmapped text.
Bill C.: What about GLX commands?
Craig: We'd need an extension to GLS. I tried to keep GLS window-neutral.
Craig: Perhaps we need to ask again whether our decision to make framesets RGBA-only is a good one.
Bimal: This could be a problem for us in terms of building our debugger on top of GLS. Windowing stuff, GLU callbacks, no differentiation between vector and scalar versions of the vertex call. But debugging is not the primary reason we'd be interested in OpenGL, it's printing. The non-distinction between scalar vs. vector would not block our acceptance of GLS.
Craig: It would be rare that anyone would need to distinguish between the vector and scalar forms. The GLX protocol does not distinguish. It would be possible for an application that needs this distinction to include callbacks that could be used to differentiate.
Craig: People should also think about the fact that framesets are defined to be RGBA.
Kurt: I think that GLS should allow index stuff to be passed.
Craig: OK.
Craig: Bimal brought up the issue of GLU implementations that might go around OpenGL and render things directly rather than issuing OpenGL calls. There are some problems encoding the GLU routines in GLS, so right now I'm proposing that we not do this.
Kurt: It seems like its a problem that glXUseXFont call does not call any OpenGL routines. This means that the GLS stream would have no information about what font was used.
Otto: The wglUseFont call makes calls to other OpenGL routines.
Bill S.: We need to be careful about embedding fonts in the GLS stream, because there are certainly legal issues in doing so.
Craig: I don't think it would be a big deal, either performance wise or code space-wise, to convert between Microsoft's GDI with embedded GLS and the true GLS. It's a matter of reordering the parameters to a couple of infrequently occurring commands and having a table lookup to map old opcodes to new.
Would people be ready to vote on this in December?
HP: yes...would like to see a public review of the "final" spec.
Megatek: yes
Sun: yes
DEC: yes...with public review
IBM: uncertain...but thinks public review would be beneficial
E&S: Strongly undecided
Intergraph: undecided...needed a printing solution but we have that now
PTC: we're interested
NCD: not relevant
3Dlabs: not relevant
Microsoft: not interested
John S. will check and see if there is any issue with the bylaws as far as adding another document to the list of those controlled by the ARB.
Kevin: Here's the occlusion culling extension proposal. Send feedback by email.