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.
Why A Layer Above 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:
Slide #1: Why a higher-level API?
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...
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...
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++
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:
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.
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:
Jon K.: Aren't important goals:
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:
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):
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?
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:
Dinner Discussions: IBM rep (Suzy?) proposed and met little opposition
with Coyote Cafe as place for the
night's meal.
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.]
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.
Implementation work includes:
David will try to organize an OpenGL++ subcommittee meeting either this evening, or in early January.
Licensing terms are not yet decided.
opengl-gamedev,
> I've just downloaded a copy of SGI optimizer/cosmo3D libs. I had a
look
> and it looks really like one of the best APIs around for 3D : full
OpenGL
> support, portability and it's Free !
> Why is SGI doing this?
To promote high-end graphics intensive CAD and 3D modeling
applications. SGI's experience (particularly based on SGI's experience
with the visual simulation market and IRIS Performer) shows that
customers and software developers greatly benefit from higher-level
APIs to that make optimal use of hardware features.
In the CAD market, this means a higher-level API that handles
multiprocessing, view frustum culling, occlusion culling, fast picking,
excellent surface trimming, use of OpenGL evalauators, etc.
> To counter D3D?
No. Direct3D is completely useless for quality CAD and 3D modeling.
Direct3D offers neither the performance or quality to do CAD or 3D
modeling well.
> OpenInventor costs over a $1000 but
> then comes Optimizer "totally" free ... well in the current implementation
> that is, the developper one should cost less than $600. The Docs
and
> sample code doesn't look that bad and I don't know if you really
need the
> dev. kit. Isn't SGI killing off it's OpenInventor/Performer line
of
> products with Optimizer ?
No. Open Inventor and IRIS Performer are mature, stable toolkits
that
serve particular market needs. Visual simulation for IRIS Performer;
rapid 3D prototyping and effective user interation for Open Inventor.
OpenGL Optimizer is addressing a whole new high-level 3D domain.
> Considering I want to program a 3D game under Windows I think Optimizer
is
> the simplest/cheapest API available ... Am I right ?
Game developers may find OpenGL Optimizer interesting for quickly
building game 3D modeling and layout tools, but OpenGL Optimizer is
probably not something anyone is going to use as the basis for a game
engine. Still, building good 3D games involves building good
3D tools,
and OpenGL Optimzier can help in this area.
> I've heard of OpenGL++ which is suppose to be like Optimzer. Does
anyone
> have any other information on this ?
The future plan for OpenGL Optimizer is to fit into a standard scene
graph framework called OpenGL++. In the future, OpenGL Optimizer,
Open
Inventor-like manipulators, and IRIS Performer-style visual simulation
will all be able to exist within a single program and all sharing a
single effective, portable multiprocessing and graphics model.
OpenGL++ is an OpenGL Architectural Review Board sponsored standard
that SGI is working to design in coordination with other ARB members.
Much the same way that OpenGL developed from SGI's experience
implementing its predecssor IRIS GL in conjunction with other OpenGL
ARB partners, OpenGL++ is about designing a standard high-level 3D
framework based on SGI's 3D toolkit design experience and working with
other interested industry leaders. Check the quarterly ARB minutes
published on the web to track OpenGL++'s development.
For more info on OpenGL Optimzier, check out:
http://www.sgi.com/Technology/OpenGL/optimizer/
http://www.sgi.com/Technology/OpenGL/optimizer/download.html
I hope this helps.
- Mark
On Wed, 29 Oct 1997, Marc Cardle wrote:
> Isn't SGI killing off it's OpenInventor/Performer line of
> products with Optimizer ?
The SGI view (and I think I agree with it) is that Performer, Inventor
and Optimiser are each intended for a different market.
Performer is for Visual Simulation (realtime performance - guaranteed
update rates, etc). There is no 'Open Performer' for the PC (yet).
Optimiser is for CAD (efficient - but not 'realtime' display of very
large
data sets)
Inventor is for rapid prototyping, presentation graphics, etc.
OpenGL++ is intended to be the underlying infrastructure on top of
which the other three are built. It is supposed to be a scene-graph
API.
OpenGL is a non-scene-graph API that OpenGL++ sits on top of.
OpenGL++ doesn't exist (yet) since it has to go through OpenGL ARB
approval stages. Cosmo-3D (not Cosmo-GL) was an abortive effort at
producing an OpenGL++ - it got into beta test and was cancelled.
This means that although Performer, Optimiser and Inventor are all
available, the common API on which they are ultimately going to be
based does *not* exist.
> Considering I want to program a 3D game under Windows I think Optimizer
is
> the simplest/cheapest API available ... Am I right ?
I'd be suprised is an interactive kind of game would be a candidate
for
Optimizer. Performer maybe - OpenGL++ more likely.
> I've heard of OpenGL++ which is suppose to be like Optimzer. Does
anyone
> have any other information on this ?
This is in the lap of the OpenGL ARB - I havn't checked their latest
meeting
notes - but I don't think they say very much.
Steve Baker
817-619-8776 (Vox/Vox-Mail)
Hughes Training Inc.
817-619-4028 (Fax)
2200 Arlington Downs Road SBaker@link.com
(eMail)
Arlington, Texas. TX 76005-6171 SJBaker1@airmail.net (Personal eMail)
http://www.hti.com
http://web2.airmail.net/sjbaker1 (personal)
** Beware of Geeks bearing GIF's. *
The ARB has made several attempts to get agreement on high-level APIs, and has overall failed, sometimes in a frustrating manner. SGI's experience is that apps need to write to a scene graph to get good performance without micro-optimization. But it's also important to be able to "reach around" the scene graph to the low level. SGI's motivation with Fahrenheit was primarily to get agreement on a good scene graph.
What happens with OpenGL and OpenGL++?