Found your article here: scribd.com/doc/4103/Scenegraphs-Past-Present-and-Future#

Can you post this pdf at your site, please?

Here is the actual history of Inventor, Performer, VRML, and Cosmo:

1. 1989-1991: Me and my team built Inventor beta.
2. ~1991: The Visual Simulation industry was in major disruption… moving from custom H/W to general-purpose H/W. Wei Yen and Tom Jermoluk smartly saw the great biz opportunity and redirected ASD (SGI’s high end) toward that market.
3. ~1991: A couple guys on the Inventor team (John Rohlf) transferred to a new Vis Sim swat team. Michael Jones started at SGI.
4. 1991-2: Michael Jones and John Rohlf decided to take the Inventor design (and code?) and make a new product out of it (and “fix the performance problems”). Thus, Performer (VisKit) was born.
5. An ugly, internal political mess ensured for many years. Performer and Inventor were enemies. It was horrible and stupid.
6. Inventor and Performer both had many happy developers, but created massive confusion in our developer base. Inventor had more developers, but Performer had more revenue impact. (WTF was I thinking?)
7. Inventor bloomed into VRML. Gavin Bell gets the credit for that. The Inventor team, led by me and Gavin, introduced the first real 3D-on-the-web in 1994-ish. It was a Mosaic plug-in that ran a simplified version of Inventor.
8. VRML bloomed into Cosmo (led by me, and then later by Kai Fu Lee). I left. Cosmo grew into a large division with 3D authoring tools, 2.5 authoring tools, and of course a 3D plugin for Netscape and IE. It was too 10 years too early (mostly because of bandwidth and client graphics speeds).
9. VRML bloomed into the ISO standard today X3D.
10. Michael Jones went on to start Intrinsic Graphics and stumbled onto an earth visualization app that later became Google Earth. Michael 1, Me 0

Background:
I was hired into SGI in 1989 by Wei Yen to add a “high-level” layer on top of Iris GL. This was like asking a new priest in the Vatican to prove that God does not exist. I hired a talented team of 3D graphics folks (read SIGGRAPH, not microcoders) and the culture clash began out the door. Paul Strauss was my first team member and the architect of Inventor (blame him for all its technical problems . It was an uphill battle from the moment we started. 99% of SGI engineers thought that GL was perfection and there was no reason to do anything new.

We had two conflicting goals in mind:
1) Modernize GL with rich OO semantics and thus enable smarter/cooler apps (3D UI, desktops, 3D cut/paste, auto-culling, collision detection, file formats, etc.,
2) an easy dev kit that creates FAST GL apps.

We were more enamored by #1 than #2. A fatal mistake.

The simple idea is that by creating an OO layer on top of the display engine (GL), we would create a true “object model” that would enable all sorts of amazing things. We were kooky-crazy about creating 3D user interfaces (see Inventor’s Manipulators) and hoped that the H/W would catch up. We wanted the SGI Desktop to be a fully 3D application. I mean, it was SGI afterall. But, we were nuts (read unrealistic). But, we drank our kool-aid and were on a mission.

Anyway, we eventually transferred out of ASD–Advanced Systems Division, the holiest of places at SGI–and joined a new software division, Visual Magic. Bad move for Inventor! This kept the Performer and Inventor teams in different buildings (probably a good thing). I would spend my nights on SGI newsgroups fighting with Michael Jones over users. It was sad. But, we did a bunch of new, cool stuff and made Inventor run AS FAST AS PERFORMER on a single-processor box. Performer was clearly better on a multi-processor box due to its separation of culling and rendering (and possibly collision detection later). But, it was too little, too late. We did prove to ourselves that we weren’t crazy. Gavin Bell deserves most of the credit for making this happen.

My understanding of the problems with Cosmo were that it was too big, too expensive, and without a business model.

I tried to reach you via LinkedIn. I am interested in citing this survey in an internal paper at Kitware, as well as re-using some of your images, with your permission. I’d also be interested to find out if the architecture that you advocate at the end is implemented anywhere, or is likely to be in the near future.

Best wishes,

Michel

Some years ago doing my MSC, one of my profesor asked if storing the graph in a relational DB would be a good idea. (He knew very little about graphics he was a database guru) I’ve said NO (with capital letters) and was shocked by the question itsels. Well, I was wrong.

I’m working on a “SG” for some months, where the object (entity) and the actual relationship b/n them are separated by functionality. eg. Physics, Rendring (DX, GL, or maybe a trace), AI, etc. goes to a different hiearchy. (sg. like model view controller design pattern, where each functionaltity is a kind of view). The basic idea is quite straightforward, but when you get there, to build up a real scene, it’s not soo trivial. My project is only in a planning phase, but it would be great to see other implementations too. So the question is that, Is there an SG implementatin following the muliview/soup idea ?