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!

----------
"Bill Gates is just a monocle and a Persian Cat away from being one of the bad guys in a James Bond movie." - Dennis Miller

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.
-- Life is complete only for brief intervals in between toys or projects -- John Dalton

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!

No, TGS doesn't own Open Inventor. SGI owns it and deserves a lot of credit for the elegant design, productivity and extensibility possible with this toolkit. At least SGI owns the v2.1 source now released under LGPL.

TGS licensed the Open Inventor source many years ago and made v2.1 available on all the other platforms (including Linux). When SGI stopped working on Open Inventor (around '96 I think), TGS effectively took over maintenance and development too. The current release is version 2.6 and is still offered by TGS as a commercial release.

---
Guillaume

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.

----------
"Bill Gates is just a monocle and a Persian Cat away from being one of the bad guys in a James Bond movie." - Dennis Miller

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

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?

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

This space for rent. Call 1-800-STEAK4U

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 ^_^

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

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

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.

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.

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.

I think the format is quite simple and sensible. Of course, I may be biased from having used it for so many years.
----------
"Bill Gates is just a monocle and a Persian Cat away from being one of the bad guys in a James Bond movie." - Dennis Miller

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.
-- Life is complete only for brief intervals in between toys or projects -- John Dalton

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

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.

My sentiments exactly.

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

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

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

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.

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?

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.

http://www.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 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!

"Yeah well ... The Dude abides." -- The Big Lebowski

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

Never underestimate the dark side of the Source

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

KidSock

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.

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

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.

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+ program without dragging Motif (or even Lesstif) along with it?

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

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

Check us out at www.coin3d.org.

Regards,
Morten (Coin developer)

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.

http://vismod.www.media.mit.edu/people/kbrussel/Ivy/

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

I couldn't find anything that specifically said Linux, but that's how the /. article is written, and that seems to be the gist of the conversation so far. (Although I'm guessing that's probably the "other" slashdot effect, Linuxcentricity)...

--First, we kill all the host programmers...

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.

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.

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.