Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Silicon Graphics

SGI Releases Open Inventor As Open Source 106

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?
This discussion has been archived. No new comments can be posted.

SGI releases Open Inventor as Open Source

Comments Filter:
  • I use Blender at home (because I only mess with this stuff for my own amusement). So as soon as I read this I thought "Can Blender and Inventor share tech, now that they are both open"? The only thing that would keep that from happening is license problems.

    But Inventor is LGPL! Woohoo! http://oss.sgi.com/projects/inven tor/license.html [sgi.com]

  • from the FAQ :

    What is Open Inventor?
    Open Inventor is an object-oriented 3D toolkit offering a comprehensive solution to interactive graphics programming problems. It presents a programming model based on a 3D scene database that dramatically simplifies graphics programming. It includes a rich set of objects such as cubes, polygons, text, materials, cameras, lights, trackballs, handle boxes, 3D viewers, and editors that speed up your programming time and extend your 3D programming capabilities.

    so, basically it's a set of OpenGL models and widgets,.. i haven't gotten to look at it in depth but if i had to guess i'd say it could be quite handy. i have yet to see it implimented in anything, though.

    someone go out and make a 3d tetris with it ;)
  • Open InventorTM General FAQ

    What is Open Inventor?

    Open Inventor is an object-oriented 3D toolkit
    offering a comprehensive solution to
    interactive graphics programming problems. It
    presents a programming model based on a 3D
    scene database that dramatically
    simplifies graphics programming. It includes
    a rich set of objects such as cubes,
    polygons, text, materials, cameras,
    lights, trackballs, handle boxes, 3D viewers,
    and editors that speed up your programming time
    and extend your 3D programming capabilities.

    Open Inventor:

    is built on top of OpenGL

    defines a standard file format for 3D data


    introduces a simple event model for 3D


    provides animation objects called Engines

    provides high performance object picking

    is window system and platform independent

    is a cross-platform 3D graphics development system

    supports PostScript printing

    encourages programmers to create new customized objects

    is fun to use

    "One World, One Web, One Program" - Microsoft Promotional Ad

  • It was used at my university to teach 3D modeling, but that class was replaced by a more advanced OpenGL course.
    OpenInventor is a superset of OpenGL, easier to use but I'd say less performant.
    But it's really easy to use which make it really fun.


  • Humm, I think there is a company (from Norway, IIRC) who did an open source implementation of OpenInventor.
    Does anybody happen to know something more? (how does the two compare?)
  • If you want an idea of what Open Inventor is, just look at VRML. VRML is based on Open Inventor. Okay, so many people will not take that to be a shining example how good Open Inventor is, but I think the failure of VRML has more to do with the implementation and the content, not the technology itself.

    Open Inventors main draw (no pun intended) is its scene graph. Basically, a scene graph is a description of everything in a 3D world. You can use it to render a scene, but its not limited to that. You could visit every node in a scene graph and instead of rendering, you could build a new data structure based on the previous one which does anything you want with the geometry. Which for me means building a display list that will draw the scene using advanced texturing and shading techniques which are not available in Open Inventor. This means that I get to concentrate on the shading, and do not have to worry about how to store my geometry. Open Inventor has a file format as well, so I don't even have to worry about creating a new one.

    I mainly see Open Inventor as a prototyping tool, because its possible to get something on the screen with very little code. I also see it as an API to use to create editors and other tools. But, does anyone know any "real" applications that use Open Inventor?

  • IRIS Explorer and a whole load of other (particularly scientific) visualisation apps are based on Inventor. Also check out most stuff by TGS like 3SpaceAssistant, and Amari 3D. I coded a load of stuff using the Inventor API last year on Windows and it really is very good - not just for prototyping but for full blown applications.
  • by Jonathan Blocksom ( 139314 ) on Wednesday August 16, 2000 @05:44AM (#851708) Homepage
    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 [gollygee.com], 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.

  • blender is closed source.
  • VRML died because in order to be interesting, the descriptor files were HUGE (I had a playfile that comtained a the ground, a floor, kneeler wall, columns, and a flat roof to a free-standing pagoda-type thing with a few scene lights so you could see it....very basic, no detail, and the file was something like 200K. And lets not forget how long it tool my P166 to render the scene...

    VRML came ont he scene too soon...before high bandwidth, before everyone had a fast computer, before it was practical to use...that's why you don't see it any more...though I still play with is sometimes...

  • In my biz (mining visualisation; you know mining as in rocks, not data :-) OpenInventor is fairly heavily used. Granted, OpenGLOptimizer is being moved to for performance reasons, but OpenInventor is still quite prevalent.

    Basically, there are lots of scientific visualisation apps out there that this LGPLed release will help. As it stands, we are now only about 1 library away (ViewKit if it matters) from having the possibility to release our apps as Open Source. (No promises, as we still must convince the powers-that-be in our organisation...)

    As always, I speak for myself, not my employer, yadda, yadda, yadda...

  • Woo hoo!

    Always wanted some of that spiffy SGI stuff, just couldn't afford it. Now I'll be able to and hack in the features *I* want. =)

    Vote [dragonswest.com] Naked 2000
  • by rmull ( 26174 )
    There's been an effort to create an open inventor clone, called coin3d [coin3d.org]. Think along the lines of Mesa - same api, but unofficial. But what happens to them now? Or perhaps more importantly, what happens to the programming contest the parent company is sponsering to get people to use the toolkit? I want prizes, damnit!
  • I never realised VRML had actually died out. I find it was always a dead easy way to code, and I never found a machine that struggled with the rendering. Even the file sizes are actually pretty small if you compare trying to do a similar thing using other methods.
    Examples are virtual worlds to explore, the virtual Mars project, a small app I coded to show family trees in a "Jurassic Park/I know this - this is Unix" kind of way:)
    Really easy to texture/image map, light, animate etc.
    The Cosmo VRML viewer works quite well on PCs now as well.

  • Whatever, as long as Linux is finally getting varied, high-end graphics attention, I'm happy. It's the biggest piece of the puzzle for Desktop Domination(TM).

    Dammit, it's got NOTHING to do with Linux. The software is now Free, which means you can build, use, and modify it on any of a wide array of systems. It's about having the source, not about Open Inventor for Linux. There's been OI for Linux/x86 for years already. I can't believe how narrow your view is.

  • It is worthwhile to note that Open Inventor is an Object-Oriented Toolkit for developing OpenGL applications. The Object-Oriented distinction is imortant as OpenGL is mostly Procedural. Scenes are trees of nodes, where each node is either a renderable object, or a modifier for its subnodes. Scenes are composed for rendering by traversing the tree and examining each node for its contribution to the final rendered scene.
  • From the FAQ: Open Inventor: * is built on top of OpenGL ... * is fun to use Anyone else find that last one humorous? :)
    --weenie NT4 user: bite me!
  • by kbonin ( 58917 ) on Wednesday August 16, 2000 @05:58AM (#851718) Homepage
    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).
  • download limit set at 50? dont SGI know nothing about enterprise servers!? should be RUnNIng LIIIIINUX!! ! !@ @ @

    Wake up and smell the sTuDlYcApS d00d. oss.sgi.com is an SGI 1000 series server. It has 2 700 MHz Intel weaklings. And yeah, it's running Linux. Maybe the download limit is there to keep ignorant fools from getting at it. Especially since you can get it by CVS too. oss.sgi.com is a lot more than just an FTP server; placing a limit on FTP connections is a sensible thing to do. Get a clue, man.

  • by NYC ( 10100 )
    Should have used preview I guess...
    Sorry for the poor formatting.

    Open Inventor:
    * is built on top of OpenGL
    * is fun to use

    Anyone else find that last one humorous? :)

    --weenie NT4 user: bite me!
  • At work we used Open Inventor for a 3D maps application. However these days we're switching to Vtree which is more powerful and has wider support. Not to mention that it's also a newer product which is constantly being developed.
  • This is very true. I guess I was bundling these problems up into 'content'. Nothing was compelling enough and it did take too long to download a reasonable scene over a 28.8 connection.

    I wonder what would happen if they tried again? Now that we have 3D accelerators and broadband, VRML could possibly be an alternative to tools like Flash. I know that Flash and VRML are very different things, but I've had just about all the 2D vector graphics I can stand ^_^

  • You will find Coin (the OS-implementation you're refering to) at http://www.coin3d.org/ [coin3d.org].

    Coin and Open Inventor should have about the same functionality. Coin has a better configure/build system IMO, and has a Qt binding (and a Gtk binding in the works), and a couple of extra Linux-specific extensions like joystick4linux and video4linux textures (not in the main source archive).

  • Maybe VRML is not dead, as much as it is not the raging success I thought it would be when it first appeared.
  • Dear slashdot, Why do we have to do your job for you? Just post a link to the Open Inventor FAQ rather than getting every /. user and his dog to rehash the damn thing here. Don't you people get paid for this? GoRK
  • Open Inventor is THE toolkit for writing 3D scenes that use the OpenGL libraries. Now that we have the Mesa libraries and Open Inventor is open sourced the world is definitely your lobster as far as desiging fantastic 3D application. Watch out for tons of great 3D applications that will appear now.
  • by istartedi ( 132515 ) on Wednesday August 16, 2000 @06:12AM (#851727) Journal

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

    Mark Pesce [hyperreal.org] 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 [web3d.org] 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

  • 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.

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

  • by gfxguy ( 98788 ) on Wednesday August 16, 2000 @06:14AM (#851729)
    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!


  • They could redirect the work into porting Inventor too as many platforms as possible just like Mesa [mesa3d.org] does with the OpenGL [opengl.org] API. With the *nix base in Open Inventor plus Coin's BeOS, and Windows versions, most people should be covered if they merged.
    Then if TGS [tgs.com] open sourced their Windows and MacOS versions of Open inventor that would be even nicer.
  • Okay, this one's going to be controversial, but I'm not trying to troll here.

    I think VRML died because it was a technology without a purpose... okay, there are a lot of uses for VRML and VR in general, but they're pretty niche.

    It's like all of those 'innovative new navigation schemes' the average Shockwave author comes out with: very pretty, but a list of links is usually more functional.

    VRML was originally hyped as the technology 'the new web' would be based upon -- we'd stop writing flat pages and have everything 3D in cyberspace. It's a marketing person's wet dream, but it's easier to read Slashdot in a nice flat font than having to "explore" the latest JonKatz column from the surface of a texture mapped octahedron. Navigating my file hierarchy with a tree-like Explorer is bad enough, let alone leaping around it like Mario.

    If three-dee was such a big deal for publishing, Playboy, GQ, et al would be pop-up books -- hey, that's not a bad idea... =)
  • Replying to no one in particular, so I'll reply to myself ^_^

    I guess my view of using Open Inventor as a prototyping tool comes from being a game programmer. As such I feel compelled to implement everything from the ground up so I can eek every last ounce of performance out it.

    Inventor could be called a tool for 'Getting It Done'(tm) which must be why it is used in scientific and visualization applications, where the application itself may be complicated enough without having to worry about how to draw everything. Sophisticated simulations are more likely to have their performance limited by sheer complexity than by graphics, so Inventor makes a lot of sense.

  • "less performant"?

    If you mean that it's possible to do things faster in OpenGL, then you are right. But generally speaking, unless you are a masochist, OpenInventor is really pretty optimized, taking care of display lists and so forth for you.

    And OpenGL isn't really accurately described as a "superset" of OpenGL, that would imply it's OpenGL and more functions - it's a C++ encapsulation of OpenGL is a more accurate description, that takes care of a LOT of dirty work for you, including picking and selecting and 3D interactivety (like the trackball and handlebox nodes).

    Any interactive OpenGL applications benefit tremendously from OpenInventor. In fact, the 3D interaction is based on a SIGGRAPH paper from way back, which described the problems of interacting with 3D on a 2D screen. SGI did a fantastic job with this, in my opinion.


  • Hooray, someone else gets it. 10 years from now when everyone's using something new, you'll hear whining "Why can't they port it from Linux to FooOS? I don't care if only 8% of the market uses it, I want it!" On the other hand, with a source release, you'll have most of the work of a port done (assuming the product and FooOS follow standards) before FooOS is even released.
  • Yeah, but most places that I saw with VRML content gzipped the files, so they were pretty small.

    "Choose a job you love, and you will never have to work a day in your life."

  • Subject says it...the BNF notation, which could easily be put into YACC or Bison, was freely available and downloadable from SGI.

    I think the format is quite simple and sensible. Of course, I may be biased from having used it for so many years.

  • Keep an eye on the older stuff [slashdot.org] page - the stuff that doesn't make it to the front page sometimes has no comments for several seconds!
  • OT, but, I think you meant:

    "The world is your oyster"

    not, lobster ^_^. I am having trouble figuring out what "the world is your lobster" would actually mean if it was correct.

  • There's also a free work-alike called apprentice. Last time I checked on it it was missing many of the animation and interaction classes which open inventor provides, but it was able to load some inventor scene graphs from files. More info on apprentice is at this site [mrpowers.com] .
  • No your post is a bit misleading.

    VRML 1.0 was based on the Open Inventor ASCII *file format* with minor extensions like links to URL's but that's about all. Open Inventor is a rich 3D graphics API with manipulators and a suite of useful tools which have also been released. Literally thousands of 3D applications have been written on Open Inventor. It is primarily a 3D graphics programming interface which also has a native file format.
  • by mav[LAG] ( 31387 ) on Wednesday August 16, 2000 @06:42AM (#851741)
    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 [chesworth.com] is a series of accessible tutorials on the mathematics and implementation of 3d graphics
    • OpenGL [opengl.org] 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 [mesa3d.org] 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 [python.org] 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 [povray.org] - a flexible raytracer
    • Blender [blender.nl] - a modelling, animation and sequence editing suite
    • Some examples [irtc.org] 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.

  • In college, I took a couple of animation courses, taught in Open Inventor. Basically, it's a handy dandy interface into OpenGL. We didn't get down and dirty with it, as it was only beginning courses (We used the OI primitives and the like). The big thing it adds (That's easier to understand than OpenGL's standard) is an object graph.
    Assume you have an arm attached to a body. You want to reach the arm out. You could rotate the shoulder, and the rest of the arm would rotate, as it would be down the object graph from the shoulder. You could add a second rotation onto the elbow, and then on down to the hand etc. Yes, you can do this with OpenGL, but the way OI does it is a bit easier to understand.
    Plus, you had a "preview" program (Can't remember what it's called) where you can basically build your models out of OI widgits, and then get the text, so you know what the coordinates of everything are, etc. One of the handiest things in the world, IMO.
  • The Open Inventor *file format* was used for VRML 1.0 but that is incidental to this product. This isn't about web graphics, (although the code could help folks working on VRML support).

    There is much more to Inventor than the file format, it is an API, not a file format, you develop powerfull 3D applications with this product, not meaningless graphics for web pages.
  • P.S.

    ...and the FAQ WON'T tell you it's a 3D format, if you'd read the FAQ you'd know what it actually was. Go read the FAQ you cite.
  • Some addendums to the other guy:

    If you're on Windows, check out www.strata3d.com
    for a decent free, OpenGL accelerated modeler.

    Also, check out www.gamedev.net. They've got some good message boards for OpenGL, and some good tutorials.

    There are some good tutorials at http://nehe.gamedev.net/opengl.asp.
  • With your math and physics background you might like to look at POVRAY.

    http://www.povray.org [povray.org]

    POVRAY is a free, open source (not GPL but something similiar) ray tracing engine which has a fairly simple language for defining scenes.

    It works with nearly every OS. However it is quite a bit different from OpenGL. POVRAY is a program for creating scenes and movies while OpenGL can be used for more interactive types of programs.

    The source distribution of POVRAY has a file called povuser.txt which will walk you through a tutorial of its general features and capabilities.

  • I have been wanting this for so long. I met the OpenInventor team about 5 years ago - smart cookies. I've been begging SGI for exactly this every year for the past 4 years.

    They did an incredible job - it's one of the best designed C++ libraries I've ever used. It's not suitable for games but for putting good 3d interactive graphics in a professional program without spending *years* learning the details of OpenGL it is wonderful.

    This is the one move that SGI could have made to prevent Direct3D winning the 3D api wars. Scenegraph based applications are an order of magnitude easier to program.

    Thanks SGI - I might even buy another SGI now (I know SGIs came with OpenInventor - but it wouldn't work gcc before)
  • Actually, the best way to describe it is OpenGL-retained mode. It is a library that sits on top of OpenGL and deals with stuff on the object level instead of the triangle level.
  • Unfortunately, the API and the file format both appear to be called Open Inventor. At least, I have heard many people use the same phrase to mean too different things.

    So, do you mean Open Inventor as in Free Beer, or Open Inventor as in Free Speach?

    Of course you develop apps with the API, and of course the apps don't have to be used for stupid web graphics. That remark was tangential to... awwww fagedaboutit.

  • Pick a crustacean, any crustacean!
  • SIM have a clone called Coin which is the one you're thinking of. There are other Open Source clones but none are complete or the official version. I hope they get merged now, since multiple implementations seems pointless, particularly if all the others are incomplete.

    None of the others, not even Coin, is complete, they just don't compare favourably, the Inventor tree which has been released is the SAME fully functional code base that applications on IRIX have been developing against for years. It is the official implementation, not a separate implementation with gaps in functionality.
  • by Mithrandir ( 3459 ) on Wednesday August 16, 2000 @07:11AM (#851752) Homepage
    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 [coin3d.org] 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.

  • Yes. Everyone was too busy typing up 20-line descriptions of what it is that they didn't have time to go for the first post.

    ('bout time we actually had an article the motivated people to type more than 'FP' as soon as they see it)
  • My contention has always been that failure to maintain backward compatability between VRML-1 and VRML-97 *seriously wounded* VRML. It isn't dead.

    As for parsers, I have seen yacc compatable grammars for VRML-1 and VRML-97. I'm not sure what you mean by trivially parseable. The VRML grammars are certainly a lot easier to understand than the C-grammar.

    I felt no need for a generated lexer/parser when I wrote my first VRML software back in '96. I wrote it all by hand, and continue to write parsers by hand, but maybe that's just me.

    Wow... all of the sudden, Slashdot==comp.lang.vrml

  • Subject says it...the BNF notation, which could easily be put into YACC or Bison, was freely available and downloadable from SGI.

    But not usable in a commercial product.

    Sure the file format was simple, but the event model was very ambiguous and open ended in many fashions - and that's after my working group spent a lot of time trying to fix it with revisions to the ISO spec and then the EAI spec following that. (Yes, I lead the working groups to do that. Check the user bio).

    I also spent a lot of time working on the J3D loader to get the model up to scratch and it is a real shit to do if you want anything other than a time zero loader.

    My understanding of X3D is that they still haven't cleared up many of the inconsistencies, just swept them under the carpet.

  • Come on - I thought "Friends" was a staple TV show for all us 20something techy geeks:)

  • Harking back to this [slashdot.org] old slashdot story from July 16 1999 (particularly when you see that the first post, #3, says "As I understand it, Performer can be builtup under OpenInventor. So why not do it right and release OpenInventor4Linux. ") I have to ask what the relationship is between Performer and Open Inventor? An SGI employee (post #17) suggests that
    "Performer focuses on maximum Performance and scalability (fast hardware, multiple processors and multiple graphics pipes), Inventor is designed for ease of use and user manipulation of 3D data. Performer also has more of an emphasis on features and file formats required by the simulation and training industries. "
    I really can't see the woods from the trees on this one......all I do know is that anytime SGI announces Free software for Linux I feel more certain that Free software will live forever, and everytime it is a 3d tool I curse the fact that I work and can't spend the next few months pulling it apart.
    Slightly OT, but we have all been talking about how the nVidia cards have the best consumer OpenGL ICD and that they will not release it to help Matrox and ATI etc. catch up........what chance of SGI (who MUST have the best OpenGL ICDs period) helping everyone play catchup instead.....then we can all have some Schweeeeeeeeeeet Free ICDs.
  • Hmm. I too thought that all of blender was open source for version 2.x, but in fact only some parts of it are. Damn. Have a look at the open source section at blender's [blender.nl] website.
  • by Anonymous Coward
    You guys don't get it. There is currently a battle for a general-purpose cross-platform open-source scene-graph(hey, hyphen city) and SGI just threw their hat into the ring, and a big sombrero it is. To get a feel for how many toolkits are out there, check out the Linux3D BOF notes from SIGGRAPH. http://www.linux3d.org (and that barely touches all of the offerings, not even considering the gaming scene-graphs, which are a slightly different focus) SGI's OpenInventor represents some serious man-years of design and development, and many commercial applications on the IRIX platform have been built on top of it. In fact, TGS licensed Inventor from SGI a few years back, and have gone cross-platform and extended it's functionality. They charge something like 8 grand a developer seat! Does this release hurt them? Maybe. It's just like any other open-source effort, commercial versions need to provide value-add over the free implementation to justify their cost. Right now, TGS is cross-platform, more loaders, large-model handling, volume rendering, commercially supported, etc. HP was rumoured to be releasing DirectModel, their large-model scengraph, it is in beta for Linux, but has yet to be release. HP has really been dropping the ball on that one, they even forgot to mention it at Linux3D BOF at SIGGRAPH. Sun has Java3D, which has a performance problem, and relies on good JavaVM on each machine. Windows has opted out, Farhenheit is dead, leaving Direct3D Retained Mode. So, yeah, this represents a significant blip on the open source radar, at least as it concerns 3D graphics. If there is enough involvment, and enough features are added, it has a chance at becoming the defacto standard, much like Mesa3D has. IMHO, it needs work in these 2 areas: - Performance Inventor has a rep for being slow or hard to speed up, due to it's scene-graph design. With todays 3D hardware increase, it may not be as significant. Thread-safety is another important issue these days. - Cross-platform SGI may not want this, but they need to realize that if any 3D scenegraph is going to emerge as a leader, it must be cross-platform. A lot of companies need to run on as many platforms as possible, if they want to get the most dollars they can. - New features Volume rendering, large models, decimation, loaders, etc. All are good things. But in summary, OpenInventor has as its strength a well-designed, mature, well-documented API that could really make a difference to the 3D community now that it is open sourced. Kudo's to SGI for finally making the decision. They're contribution will help set the bar for a minimum quality that the other efforts will have to compare too. Smart business move, too, imho, because people may start with Inventor, and finally demand more performance, which will lead them to Performer or SGI's hardware. It's SGI's job to make that value-add significant enough.
  • Careful. I could put IRIX 5.3 on an Indigo and I'm pretty sure it wouldn't handle it. If you mean an origin (which would most likely run irix given that linux on such systems is quite experimental yet) instead of the crap sgi is trying to pass off as "servers" these days (x86, what a sick joke), then yes, absolutely you are right. But simply running irix does not a server make.
  • by Performer Guy ( 69820 ) on Wednesday August 16, 2000 @08:01AM (#851761)
    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.
  • You were probably using a modeller that couldn't export optimized VRML code.
    VRML was, in this aspect, pretty similar to HTML: you can write code by hand and produce tight, optimized files, or you can use FrontPage and produce bloat. Of course, it was quite more difficult to code 3D scenes on your own, by hand, (which reminds me of my POV-Ray using days... but I disgress), but that's why you had gzip for.
  • It's the Open Inventor file format, there are two flavors, ASCII and binary. 3DStudioMAX has a file format, but you don't call 3DStudioMAX a file format, you call it a modelling and animation package.

    It's LGPL, it's free speech..... and beer if you used to pay $4000 for a licencse from a private vendor.
  • This is slightly offtopic, but important none-the-less.

    As most of you know, the GeForce2 Ultra Windows drivers took a jump to version 6 (detonator 3.) However, it seems that most of the performance improvements in Detonator 3 are already in the Linux OpenGL driver. That's a bad thing. Since it seems that the Detonator 3 drivers improve performance by 20% or so on average, it means that the benchmarks where Linux was running neck-and-neck with Windows were inaccurate. If benchmarking is done between equal platforms, Detonator3 and Linux OpenGL, it might show that Linux was still 20% or more behind the performance of the Windows drivers. Is anybody aware of such a test? Also can anybody back up the fact that the Linux OGL driver contain the tweeks in Detonator 3. My source was some guy on Slashdot, be he seemed to know what he was talking about.
  • This is an interesting point.
    VRML used the ASCII 3D format which is naturally very large, much larger that a binary equivalent and a binary inventor format existed, although compressing the ascii should have been possible.

    I expect the motivation was to allow people to text edit the data in ascii format, much as you can with html. This is a strength of Inventor but it's getting to the stage where this kind of thing is impractical.
  • Your releasing your app as Open Source is not predecated on the underlying libs being Open Source. You could go ahead and release your code today, building them would simply require a developer to own the prerequisites.
  • My sentiments exactly.

    "Woohoo! A software title is now open source! High fives, everybody. Erm, but can someone tell us what it is?"

  • SGI has done as much as it can Open Sourcing the OpenGL SI, and infact they have announced new terms releasing the conformance tests too.

    On the diff between Performer and Inventor, the text you posted is completely accurate although Performer is not Open Source.
  • Just thought someone should point out that in the Java word we have Java3D, a very very nice scene graph system, that's now in Version 2 with added features. (I wouldn't be suprised if I fodun otu the the J3D guys were inspired by some of inventor's ideas, seeing how long ivnetor has been around.)

    J3D is portable across udnerlying 3D libraries. Currently there are version for both OpenGL and Direct3D.

  • Let's not forget that like other Open Source scene graph libraries (PLIB's SSG, &c), OpenInventor uses OpenGL's Retained Mode...that is to say, it's faster than you give it credit for. It builds display lists to generate scenes: that is, it buffers every node in the graph before displaying them, speeding up the rendering process by a lot...
  • If Open Inventor was ported to all the platforms that Java runs on, then you might certainly see some speed improvements in J3D, as the higher level encoding could be handed to OI.
  • I did some Inventor programming at SGI under version 1.0 before GL was Open GL. In simplest terms, it is a higher level toolkit that abstracts away vertices, viewing transforms, etc much in the same way GTK and Qt abstarct away underlying X11 Intrinsics. It is very useful for rapid prototyping. You could very easily build a viewer to look at your data becuse it had simple means for inserting your data in a scene graph and then attaching a viewer to it. It took no time at all, very quick and easy. The viewer object had UI controls for pan, rotate, zoom allowing the programmer to concentrate more on their data or their app than dealing with mundane issues of how do picking and rotate handles. It was also built with the intention of providing the fastest possible path through GL. It would use triangle strips where it could, try not to use modes that were slow, etc. The .iv formta was a great way to portablely store geometry data as well and proved to be the basis of VRML. The toolkit was also extensible, you could subclass and create new geometry types, new viewers and controls as needed.

    On the down side, it tried to be all things to all people so it was (at the 1.0 level anyway) very large. It had a huge number of methods and a gigantic symbol table (link times were a little slow.) Also, because it implemented a scene graph to enable fast drawing and abstracting the data rep away from you, it often meant that you ended up with 2 copies of our scene data unless you built the app to use Inventor specifically from the begining. i.e. I was asked to attach an Inventor viewer to an existing app. I would have to take the data structures from that app and pass them into Inventor's Scene Graph via the Inventor api, where this data was duplicated in Inventor's internal data structures. Even freeing the external apps data rep meant that the memory was still around, just ready to be used for the next malloc, which either lead to fragmentation of high memory use.

    All of these observations are based off of 1.0, not sure what it looks like now. I'd use it again, but if I were building an app aroudnd it, I'd make sure that I designed the data structures to mesh with Inventor well.

  • 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!
    TGS has never owned Inventor, they just licensed it from SGI. As far as I know that license expires sometime soon (not exactly sure when).

    TGS's version of Inventor, however, has several things in it that the Open Source version doesn't have (yet). These include the capability to load VRML 2.0 files and thread safe code.
  • From the FAQ: [sgi.com]
    What are the prerequisites for building the Open Inventor software? Linux (glibc 2.x) or IRIX, X11R6, Motif, C++ compiler and OpenGL.

    Does anyone know how closely tied it is to Motif? Is it the whole thing, or just a small part? How hard would it be to use it in, say, a GTK+ [gtk.org] program without dragging Motif (or even Lesstif [lesstif.org]) along with it?

    (I would download it myself and take a look, but their server seems to be /.'ed.)

  • I had suggested to them several times that a crossbreed toolkit could be called 'Informer' :-) Or, 'Preventor'. I think the Performer team is catching on - there might be some notification schemes soon in Performer like Inventor sensors. Remember, the reason performer is still alive is because of the Defense department likes it. So, since there really isn't a need to pick a tank and spin it like a CAD model - performer will stay a vis-sim toolkit.
  • 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.


    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.

  • OpenInventor is interesting from C++, but it's really powerful when it's combined with Ivy

    http://vismod.www.media.mit.edu/people/kbrussel/Iv y/

    With Ivy, you can mess witb OpenInventor interactively, from the scheme prompt. Can't beat it!

  • I don't know how closely tied it is, but it is tied, and it has some custom controls written for Motif. That said, I think you could pull off using both, as long as everything was in seperate windows. But that's just not quite as nice as having your program contained in one window. I don't know how receptive they be to merging GTK support (or Qt support) into the main source tree if someone wrote it.
  • I've used Java3D for a commerical game proejct extensively and foudn no speed problems to date.

    And why should putting it ontop of OI make it any faster?

    As has been already posted and discussed, Java computational performance is a match for C+= today. (See Chris Rijk's excellently researched and analyzed article "Binaries v. Bytecodes" on www.aceshardware.com.)

    Going to native code can actually slow down Java applications. For an explaination on why this is true, see the Native code section of the book "Java Platform Performance: Strategies and tactics."
  • Bunches of reasons, but you nailed it right on the head -- not in the way you believe, though.

    The best thing about VRML is that anybody can make a VRML model. It's plain text (utf8) and marvelous worlds have been built using nothing more than vi or notepad. The worst thing about VRML is that anybody can make a VRML model.

    A 200K file for a little bitty building is obscene. You absolutely did not do this by hand. You got it from a modeler that exported VRML, and you figured, "hell, it parses, let's put it on the Web".

    I'm not singling you out. Far from it. The thing that was the absolute worst PR for VRML was that easily half the VRML worlds out there were bloated pigs just like your world. That's because hardly anybody valued small, fast worlds, and even fewer knew how to build them. For instance, I've got three VRML decimators (one uses Garland & Heckbert, one uses Hoppe, and I don't know what the third one uses), and I wouldn't dream of publishing a VRML model on the web without sending it through at least one of the decimators.

    And don't get me started on color and lighting. Jesus H. Christ, you can do beautiful things with lighting in VRML. You don't have photon tracing (which means the scene will render in your lifetime) but you've got enough effects to make something really beautiful. Not one world in a twenty uses anything but the headlight and primary colors. That alone is responsible for VRML's rep as "cartoonish".

    There are many better examples than this one [hiwaay.net] of what you can do with color and lighting when you take a little time, but I might as well toot my own horn.

    Rev. Bob "Bob" Crispen
    The VRMLworks [hiwaay.net]

  • As has been already posted and discussed, Java computational performance is a match for C+=[you mean C++ ?] today.

    I have not done any J3D and only a little AWT and Swing but I have done a ton of Java(http://jcifs.samba.org [samba.org]) and I frankly don't see how what you say above is possible. Java is slow. Java AWT is slower. I found the article you mention but just don't have time to read the whole thing at this moment. You have a relavent section you can point me to? A string I can search on using find in the browser would be great.


  • Meanwhile folks smart enough to invest in real infrastructure software for B2B or eCommerce made a killing.

    What does B2B stand for?
  • ...and Open Inventor has been available for Win32 platforms for years through TGS - and it integrates superbly with Visual C++ 6.0. From nothing to a working Inventor app in 30 minutes with this, that can open, save, print, etc...
  • I have a slightly different perspective on this. IMO, the main reason that VRML died was because the tools were pretty much Windows and IRIX only, at a time when most 'net content was created by Mac designers working with Unix (but not necessarily IRIX) people.

    My name is Sue,
    How do you do?
    Now you gonna die!
  • I will accept that I should have clarified my comment more carefully, here goes: "Inventor derivation for VRML was first and arguably most signifigant step in making adoption of VRML difficult, which let to its current zombie-like state". But then that wouldn't fit on a subject line, eh?

    I agree that ultimately "utter lack of demand at that time for 3D on the web" was the ultimate problem. But VRML came out at a time when, if implemented properly (i.e. high-speed plugins), it could have stimulated that demand. Those in the community continue to becry the need for "the killer app", without realising that games continue to distract the 3d mass market, and hold a bar far past the 'academic' (i.e. more accurate color model but 1/10 the frame rate) rendering pipelines available for VRML.

    Also, there is a relationship to Fahrenheit here: SGI invested a great deal of time and resources on this new scene graph model, only to have Microsoft steal some of their best people and introduce the platform restriction. Releasing OpenInventor as OpenSource is an attempt to regain mindshare in the scene graph API space that they lost when Fahrenheit was dumped back to MS.

    I'm not attributing bad motives to SGI, the LGPL Inventor release was a "good thing" (although I'd like to see a less encumbered license.) I also still remember quite vividly that they promised for SEVERAL YEARS!!!!! to make the VRML grammer available for unemcumbered use, and never did, and ultimately sold it to a corportion that merely sat on it.
  • I might even buy another SGI now (I know SGIs came with OpenInventor - but it wouldn't work gcc before)

    Only the runtime for Open Inventor was supplied with IRIX. The developer kit was always available for an extra charge (until now I guess).

    Anyway this is very exciting news!

  • To really udnerstand the results you need to read Chris Rijk's article. There really isn't a lot of fluff there, it's all pretty much to the point. You can't understand an issue as complex as comparative peformance charcteristics from "soundbites" or annecdotes.

    BUT if you want a soundbite, the soundbite is this...

    There is no magic here. Java compiles to native code just as C or C++ does. At run-time however (when Java compiles) there is optimization information on what your program actually does that is not available at "build-time" when C++ compiles which thsu results in ebtter optimisation of the code.

    Additionally Hotspot does "risky optimizations" because it can back them out if the guesses prove wrong. This is something a build-time compiler cannot do.

    Finally, you can amke any code slow but ineffective/inappropriate programming. Most Java prgorammers are still very new to the language and how it works. It hasn't been around long enough for a body of practices to build up yet.

    In that regard, I find this whole "java is slow" thing frankly ratehr amusing. If yo uwant to take a time-trip back 5 years, take any senatce with the words "java is slow" in it, and repalce the word "java" with the word C++

  • Releasing OpenInventor as OpenSource is an attempt to regain mindshare in the scene graph API space that they lost when Fahrenheit was dumped back to MS.

    Microsoft announced that they will not be productizing XSG (what they ended up calling the Fahrenheit scene graph). There wasn't any lost mindshare to be gained back.

    I also still remember quite vividly that they promised for SEVERAL YEARS!!!!! to make the VRML grammer available for unemcumbered use, and never did, and ultimately sold it to a corportion that merely sat on it.

    If you're referring to Cosmo3D, what happened was a little more complex. Cosmo Software was spun off and acquired by Platinum, who did publically commit to open sourcing Cosmo3D. However, Platinum was then acquired by CAI (at which point I believe the remaining Cosmo engineers left or were laid off), and CAI didn't follow through.

  • The windowing part of Open Inventor is contained in a separate library called libInventorXt.so.

    There's nothing stopping you from opening up your own window and then tying the rendering context it.

    libInventor.so (the core Open Inventor library) is window system independant (mostly). The only exception I can think of off the top of my head is the offscreen renderer which has some X code (but no Motif.)

  • Although I've not taken a look at this in some time there are Java bindings for Open Inventor available at the following URL:

    http://www.igd.fhg.de/CP/kahlua/ [igd.fhg.de]

  • There is no magic here. Java compiles to native code just as C or C++ does. At run-time however (when Java compiles) there is optimization information on what your program actually does that is not available at "build-time" when C++ compiles which thsu results in ebtter optimisation of the code.

    I'll have to say "bull" on this one. What extra information would byte code have that source code wouldn't? Sound's like a perpetual motion machine to me. Just feed the byte code back into a "byte byte code compiler" and get super duper optimized code. Seriously, though optimizing code paths in a running program is the only thing Java has up on plain ole C++. I say plain old, because C++ makes compile time vs. optimization vs. size trade offs. But if you look at super optimizing compilers Digital/Compaq's new C/C++ compiler or add on packages like Intel's VTune or the GNU Super Optimizer, you start to see some of the tricks that Sun uses on Java.

    The reason Java performs pretty decently nowadays is because Sun had to invest heavily in alternative algorithms and compile strategies. Example is the benchmark Sun showed proving Java could allocate/deallocate memory faster than C++. It only proved that Sun's memory algorithm was better. If you could bolt their memory allocator onto a C++ compiler, you'd probably see the pendulum swing the other way.

    Comparing Java to C++ is like comparing different CPU architectures. On the surface they may appear equal (or one appears better) but when you start to look at the work per clock you start to get an idea of how efficient each CPU really is. Java may have cool tricks, but you're going to lose performance some where. If you thought C++ programs took forever to load, look at Java. Now, instead of the inconvenience of waiting for code to compile, you now have the inconvenience of waiting for it to load (or load parts of it) -- only to get achieve the performance plain ole C++ has been providing for years.

  • Take this from someone who was part of a LONG project to get Java 3D working up to the level a naive person would expect after hearing the Java hype... it ain't happing.

    The performance of Java 3D is abysmal. Sure, you can build a few 3D molecules, but try mapping video onto it in real-time. Uh-uh; no way. Try powering it with a big graph, oh, say 30 objects or so (*nothing* in OpenGL)... forget it. Open Inventor is not the fastest engine on the planet (not supposed to be), but it's WAY faster than Java3D.

    I still hold out hope for Java. It's got a future as a replacement for CGI, or database clients, but don't even think of using it where you need performance and access to system level hardware acceleration.


  • by Al Wold ( 5038 )
    Right on. If only it were real SGI's running IRIX, then all of the people could download it... Even though they don't even know what the fuck it is. Now where's the free IRIX version? :)
  • sucks. a language for trendy linux fucks. use perl or something, dammit.
  • that sucks. if i was them i'd use something that is actually stable...maybe irix.
  • and it integrates superbly with Visual C++ 6.0. From nothing to a working Inventor app in 30 minutes with this, that can open, save, print, crash, lock up, hang, blue-screen, toast your machine, ...

    Just couldn't resist. :) And yes, I've worked with OIV on that platform. There's nothing you could offer me that would get me to use a microsoft product ever again. *shudder* Just thinking about that experience is disturbing.

  • No, your data around Fahrenheit are just hopelessly wrong, what's disturbing is that you presented this as if it were fact and it's in such diometric opposition to the truth.

    Most of the errors are glaring but I'll address the most glaring offensive to the real engineers at SGI:

    You claim Microsoft stole SGI's best people. I can't think of one. I think one engineer form SGI did some contracting for Microsoft after SGI halted it's efforts on Fahrenheit but Microsoft didn't steal any of SGI's best people, never mind the hoards you imply. Good people have left SGI at various times for places like NVIDIA, ArtX, ATI, 3DFX and others but I can assure you that Microsoft isn't the place SGI engineers dream of working in, the very opposite is true. The assertion is almost comical, and they can keep Rocket Rick Beluzzo, he exploded on the launch pad after FSG hit the fan.
  • No, this isn't a major scene graph dominance play. It will help apps on Linux, there may be a resurgence of interest in Open Inventor, customers can get Inventor on Linux and Open Inventor support will benefit. To see this is SGI's hat in the ring in a scene graph war is a mistake.

    It would never fly, not after Cosmo3D, OpenGL++ & Fahrenheit. The API story has come full circle and landed back at square one, if you look at the history of this you might guess why but there are other scene graph products supported by SGI based on customer demand, it's not about scene graph wars. The time for that has passed, there's a more pragmatic climate out there and as others have already observed, scene graphs make distinctive design tradeoffs which affect suitability for specific markets. For example SGI also has Volumizer, Performer, and Optimizer which fulfill rather specific requirements which Open Inventor isn't ever likely to address.
  • You are ignoring the immense value that an off the shelf format with extant support brought to the table. You are taking one single aspect of the Open Inventor file format which you see as negative and using it to critiqe the choice while completely ignoring the many merits of the file format. That is a completely biased approach.

    Nobody can say for sure what else might have emerged in those days, but I'd guess it would have taken way longer, may have ended up worse than Open Inventor and would have ultimately fared no better in the market. The Open Inventor choice helped support for VRML especially early on, that seems obvious and contradicts your claim. Could the format be improved for some applications? Yes. Was there a better choice available for VRML? Probably not.
  • We at the Coin project (i.e. the API compatible Inventor clone) have bindings for Qt and GTK+ (and Win32 and BeOS). The Qt binding is near complete (works with both Coin and Inventor, BTW), the GTK+ and Win32 bindings are "in-the-works" (fully usable for most Inventor applications, though), while the BeOS binding has been put on the backburner.

    Check us out at www.coin3d.org [coin3d.org].

    Morten (Coin developer)

Dynamically binding, you realize the magic. Statically binding, you see only the hierarchy.