SGI Releases Open Inventor As Open Source

SGI has released Open Inventor (TM) 3D graphics toolkit to the open source community. You can read the press release here and their FAQ here. I'm sure many people will ask what is this Open Inventor, so could a /. reader give a few words about it?

Comments

Open Inventor

[Jonathan Blocksom]

I've done some stuff using Inventor in the past, here's a non-marketing person's overview. Open Inventor is a high-level 3D graphics API which sits on top of OpenGL. With Open Inventor a programmer can work with objects, materials and cameras in a scene graph framework rather than having to deal with polygons, color/texture/lighting/material calls, and transformation matrices in their own data structure. A scene graph is a big tree which contains everything in the scene, well suited for hierarchical models.

Open Inventor is great at rapidly creating interactive 3D applications. By 'interactive' I mean things where the user can get in and pick objects, move them around, etc. Open Inventor takes care of all the rendering and events for you and so it's pretty easy to get something up and running. Performance is good but not Inventor's main thrust -- so it'd be better to write something like a model or level editor in inventor than a first-person shooter.

I've seen Inventor used to create an architectural modeler with great effect; the author was really able to focus on the interface and not spend a lot of time reinventing the wheel for his underlying data structure. We considered using Inventor for the project that eventually became my children's 3D building blocks program, but there were licensing issues and we didn't think the performance would be there by the time we wanted to release it. If I were starting again today, I might reconsider.

Inventor derivation for VRML killed VRML

[kbonin]

Inventor is a good scene graph, albeit overly complicated. The problem is that its scene graph file format is not trivially (left-right) parsable.

When the early VRML specification was derived from Inventor, (the spec writers used several other open source specs including one I contributed to), they based the file format on Inventor. This was good for them, as they worked at SGI and had access to the parser source.

However, nobody ELSE had access to the parser source, and the complexity of its recreation, along with critical ambiguities in the original spec, made recreation a many man month ordeal. Until recently, those parties that did go through this ordeal chose to sell their implementations under somewhat expensive commercial licenses.

This is why so many applications could export VRML, but few could read it back in. This led to the spec remaining in the hands of a few commercial entities, where it has remained despite claiming an "open" consortium (that you must purchase a seat on.)

The new X3D spec is an interesting mapping of older VRML onto XML, but instead of simplifying things they chose (surprise) to map directly, retaining much of the original problem.

Inventors source release probably has more to do with Fahrenheight(sp).

Re:Inventor derivation for VRML killed VRML

[Performer Guy]

There are several corrections which should be made here.

First the left right parser in order graph traversal just applies incremental state changes to the OpenGL state machine. This is easy, the application of these state changes is extremely well documented, intuitive and trivial.

Second, this traversal design has advantages and disadvantages, but it is a conscious decision. It is actually a powerful and intuitive way of structuring a database where as changes get made to a scene graph they have repercussions for the appearance of objects based on the predictable drawing order, this is how all graphics hardware works today and the state engine in OpenGL is the primary motivation for doing things this way.

Third, this approach seems efficient from a graphics and processing standpoint, unfortunately it is not. The main problem is that when you draw an object in the middle of the graph it's appearance potentially depends on data at any stage previously encountered in the graph traversal, this is entirely predictable but you still have to traverse the graph and at least check for the possibility. So, on balance I think it's the wrong approach but I can understand the motivation.

Fourth, this is DEFINITELY NOT what killed VRML, what killed VRML was the utter lack of demand at that time for 3D on the web. SGI sunk millions into the Cosmo effort and pulled the plug when the "second web" didn't happen (OK you might say it did but it wasn't about 3D cartoons in a web browser). With hindsight there was insufficient interest to justify the expense of making 3D easy enough to be viable. Meanwhile folks smart enough to invest in real infrastructure software for B2B or eCommerce made a killing.

Just look how fast VRML died when SGI stopped pumping millions into it's development & promotion. It practically vanished overnight but it was an Open 3D format, and it was good enough as a standard to get used if it was needed. Just look at some of the horrendously bad standards out there. The traversal order issue is trivial by comparison and certainly didn't affect the acceptance.

Finally, this Open Source release has zip, nada, zero to do with the Fahrenheit project. It is definitely a grass roots effort, I know because I saw it happening and I saw the engineers (and a few folks in marketing) arguing passionately for this to happen. If Fahrenheit were still around it might have been different but one of the reasons Fahrenheit isn't around is SGI's commitment to Linux and inability to get Fahrenheit on that platform so there's nothing sinister here. This release is about helping Linux growth and applications availability, improving support for Inventor, and meeting customer demand for Inventor on Linux.

Some History.

[istartedi]

Open Inventor, as the FAQs will tell you, is a 3d format designed to work with OpenGL.

Mark Pesce used Inventor as a starting point for VRML-1 around 1995. VRML-1 was the first real attempt to create a standard 3d file format that would work over the web. It has seen limited success as a standard of exchange betweed CAD programs.

A second version of VRML based loosely on VRML-1 (but not backward compatable with it) was proposed by one of the major industry players and rapidly became an ISO standard in 1997. By many arguments, it failed as a standard because the required plugin is not installed by default. There are other reasons too, but by and large, mention of VRML still gets a "huh?" even from some fairly computer savvy people.

The next version of VRML being developed by the Web3D Consortium is based on XML. The tags are designed such that conversion from VRML97 to X3D is quite straightforward. If X3D is built into IE and Mozilla, we could finally see the standard VR format gaining acceptance.

As for all the Open Source software flying around in the 3d community now, it tends to make things less exciting from a money point of view. OTOH, I'm sure the same web designers who like to make bandwidth hogging flash sites are getting very excited now.

I am obviously biased in certain areas. Other, less biased histories can be found at: http://hiwaay.net/~crispen/vrml/history.html

Re:'this could be useful...'

[gfxguy]

i have yet to see it implimented in anything, though.

Maybe you haven't, but I can guarentee you've seen the results. VRML is based on OpenInventor, for example.

Projects I've been directly involved in that used OpenInventor include: Virtual Sets (On TBS and TNT, for "Inside the NBA" and "NFL halftime shows", as well as "People Count", a public service show), Moxy Moto (a character on the Cartoon Network awhile back), and "Kenny's Kourt" (formerly "Court Vision") on Inside the NBA.

Not only do you get "scene graph" management, but as you mentioned, you get 3D interface tools for interacting with your models, very easy selection methods for choosing parts of geometry, and really nice callback features. All this, and anything it can't do can simply be done in OpenGL, since that's the rendering context it uses anyway.

If you can't tell, I'm very excited about this. I've been looking at open source alternatives, but haven't really been totally happy. TGS already had a linux implementation, but for us hobbyists it was quite expensive, and had a really restrictive license (everyone who used your software needed a run time license).

But I thought that TGS (template graphics systems) "owned" Inventor now...maybe they just licensed it and the contract just expired, I don't know, but TGS has been the company maintaining it for the last couple of years. I'm really quite excited about this!

----------

Re:Offtopic, I know, but ...

[mav[LAG]]

How do you even get started doing 3D stuff? Both still images and animated 3D? I'm looking for cost-free stuff that isn't cripware to get started. I have a very strong math/physics background, so I have no problem describing equations of motion, but I haven't the faintest as to how to get started.

It depends. If you want to program still and animated 3D graphics, then you have quite a few choices. Here are a (tiny) subset of the ones I know:

• Here is a series of accessible tutorials on the mathematics and implementation of 3d graphics
• OpenGL is the API of choice for most platforms. Simple, clear and easy to understand. It does assume that you know what the basics are though.
• Mesa is a free workalike implementation of OpenGL for most platforms. Reading the source to the included demos is a good way to start learning.
• Python is a very good language with OpenGL bindings with which to start messing around. If C and C++ seem too tedious just for experimenting then try PyOpenGL. Python itself can be learned in a weekend after which the GL module is there to play around with.

If you're not interested in programming - just modelling and creating then check out:

• Povray - a flexible raytracer
• Blender - a modelling, animation and sequence editing suite
• Some examples of what is possible

All of these tools and references are free and work on Windows and Linux alike.

Also, how prohibitive is the hardware for this kind of thing?

All you need is a resonable midrange PC and a decent accelerator. A hardware-accelerated graphics card on your platform is a must to view complex 3D graphics at any kind of framerate. Vendors with good Linux support include include Ati, nVidia, Matrox and 3Dfx.

Re:'this could be useful...'

[Mithrandir]

VRML is based on OpenInventor, for example.

Not quite right. VRML 1.0 was based on OI. VRML 2.0 is not and barely resembles it terms of capabilities.

In the end, both try to do the same thing: Scengraph based graphics representation, User programmable behaviours, customisable/extensible node types. They just do it in very different ways.

But I thought that TGS (template graphics systems) "owned" Inventor now...maybe they just licensed it and the contract just expired,

Correct. The interesting thing that I want to know is how does this news effect the Coin3D folks who already have an OSS (QPL) version of OI. They were showing this off at Siggraph and it looked pretty complete and very quick.

Open Open Inventor, from one of its developers

[Thagg]

I worked with Rikk Carey and Paul Strauss, and the rest of the Inventor team from '92 through the release of Inventor 1.0. There were wholescale changes after I left, but I think that my experience is worth sharing here.

Synopsis

Ultimately, Open Inventor is useful as a 3D prototyping tool. It's a great way to get a simple, interactive 3D program running quickly.

Beyond that, I don't think that it's particularly useful. It falls into the classic trap of 'jack of all trades, master of none'. There is nothing that it does particlarly well except prototyping; so there are no rich Inventor applications.

My experience with Inventor

When I started at Silicon Graphics working on Inventor, (or Scenario as it was called at the time) I was filled with optimism and excitement. This tool was going to make 3D ubiquitous. I had thought that the reason that there were so few 3D applications was that they were too hard to write; and that by building a generic high-level toolkit we could solve that problem.

The big problem ended up being that by building a high-level toolkit; you end up taking over the application. If you want to provide high-level functionality, you necessarily have to circumscribe the possible applications. You have to adopt the Inventor scene graph, nodes, and traversal. These may not be appropriate for your particular application, in fact, they are almost guaranteed not to be. You can extend Inventor by creating your own nodes, and several users have done that to get more performance; and a closer match between their application and the Inventor infrastructure -- but that's only a step along the way to creating your complete independent application IMHO.

There were great things about the Inventor development experience. I have never worked with as bright or dedicated a team of programmers as Carey, Strauss, Paul Isaacs, Nik Thompson, Dave Mott, Dave Immel, Josie Wernecke, and Alain Dumesney. I was in charge of backups, and it was not uncommon that almost every of the hundreds of source modules was changed in a day -- we were making large scale changes at an incredibly rapid pace as we prototyped, learned, and experimented. ILM was one of our beta-sites, and they got more out of Inventor than I ever thought that they would.

Inventor also cured me of C++. It seemed at first that C++ would be perfect for something like Inventor; but it was a near disaster IMHO (not shared by everyone on the team, I should point out.) C++ gives you some extra rope; but it quickly becomes tangled around your neck.

The biggest problem by far was nodes and traversals. You can think about them as two different dimensions. Nodes are things like cubes, cylinders, materials, colors, lights, and so on; while traversals are for rendering, bounding box calculation, printing, and the like. Nodes are the nouns, and traversals are the verbs.

C++ works for one-dimensional extensions, but we had to resort to a traditional function table to do this two-dimensional extension. It works, but it's a mess; and the language only got in the way instead of helping. This is only one of the many examples were the promise of C++ was not only not fulfilled, but was shown to be the exact opposite of what was promised; it hindered rather than helped.

Going forward

At Siggraph this year, there were no less than four scene graphs for Linux discussed during the Linux/OpenGL BOF meeting. I wish them luck, and hope that they find something useful in the Inventor source.