ARB Meeting Notes
ARB Meeting Notes
| 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 |
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.