RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open source + Performer for Linux)

[Matthew M. <ma...@me...>]

You Know;

Hewlett-Packard did an elaborate scene-graph API with fairly advanced
OCCLUSION CULLING, (i.e. more than just portals or HOMs) originally as part
of Fahrenheit. It was called DirectModel, and it has been used to ship
products. (by EAI, for one.) Its primary focus was extremely large datasets
(engine simulations, etc.) It was originally only part of the Visualize
Toolkit.

Now, the interesting part is that they recently gave a grant to the
University of Tuebingen (Germany?) to convert DirectModel to Linux and
release it as open source.

While such release has not yet happened, I do believe I've found the group
that's doing the conversion:

http://www.gris.uni-tuebingen.de/~bartz/proj/large/#occlusion

The project has been renamed to "Large Model Rendering Toolkit."

They don't specifically mention it on the site (I assume it's not ready,)
but there are some enticing papers up there in Acrobat format.

-- Matt

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Graham S. Rhodes
Sent: Wednesday, September 06, 2000 11:27 AM
To: gda...@li...
Subject: RE: [Algorithms] FW: [CsMain] Scene Graphs (Open Inventor open
source + Performer for Linux)


Steve wrote,

> Yes - but Inventor isn't really appropriate for high performance
> stuff - that's why SGI have the 'Performer' scene graph for that kind
> of thing.

I agree! You'll note that I stated as much in my original post, at the
bottom, item #5 and the following paragraph. (I sometimes have the same
habit as you----replying to a message before I read or fully comprehend the
entire message. Or before I check to see if someone else has replied with
the same response. But I'm getting better!) Its probably good that you
stated your comment on Performer vs. Inventor at the top of your message,
since possibly someone else didn't read to the bottom of my long message.

Even so, you'll be interested to know that our customer has been able to
display models up to around 250,000 polygons (tris and quads) in Inventor,
on an HP Kayak PC with fx2 graphics. Frame rates were not good, though, for
this model. With a 100,000 polygon model frame rates were much better, of
course. Modern consumer T&L boards, which are much better than fx2 graphics,
would result in better performance for the larger model.

It is absolutely true that Inventor does not actively manage performance the
way Performer does. It really is meant for inspecting objects and
manipulating objects rather than navigating through large worlds. I do think
Performer is going to be a better engine for games. But, alas, Performer
doesn't work on Windows or Macintosh. Only Linux and IRIX. And it is
unlikely that it will ever be ported to the more popular platforms.

> Inventor is more for makeing cute presentations, rapid prototyping,
> that kind of thing.

We use it for a bit more than that. We have an Inventor-based model
assembler (developed from 1996 through present) that we use to build models
of NASA's Next Generation Space Telescope (NGST), pressure vessels for
studying Mars habitats. And others have used our tool to assemble various
large aircraft models (e.g., high speed civil transport). We assemble the
model and apply loads and boundary conditions/constraints in our Inventor
app, then invoke a multidisciplinary analysis of the assemblies, and finally
import and animate the results in Inventor. For example, we've done an
analysis of the NGST where nonlinear structural vibration was induced by
radiation loading from the sun in space. The animation data is over 300MB of
motion and scalar contour data (12000 time steps) for the vibrating space
telescope. Inventor handles it just fine. The model itself is not as big as
the large models mentioned above, though. We do the postprocessing as well
in a Performer app, which maintains a relatively constant frame rate
compared with the Inventor app.

> > It is an extensible/programmable scene graph engine that is
> quite powerful.
> > It has a "standard" file format as well...
>
> It's essentially VRML...or more accurately - VRML is essentially
> Inventor.

Folks should keep one thing straight. VRML is a file format. Inventor is
both a file format and an extensible C++ scene graph toolkit. When comparing
Inventor and VRML, you can compare their file formats. And you can compare
the Inventor toolkit with VRML file browsers. In general, it is *not*
accurate to say "VRML is essentially Inventor" or vice versa.

It is true that the VRML version #1 file format was based on the Inventor
file format. Inventor's file format is both a superset and subset of VRML 1.
Inventor has features, such as calculator engines, that the VRML 1 file
format does not have. And VRML 1 has features that were not in Inventor
(billboard node, sky/background node?). VRML 1 is quite obsolete, and
Inventor is not related to the more current VRML97 (version #2 of VRML).

Inventor the *engine* as opposed to inventor the *file format* is a HELL of
a lot more than simple VRML #1 viewers in terms of programmability and
extensibility. It is *not* merely a viewer for simple files. It does allow
you to build interactive scenes and customized 3D interaction, even though
it is not the best SG engine for this kind of application. You can write
OpenGL callbacks to implement cinematics, etc. VRML97 viewers that support
ECMA scripting or EAI allow significant customization and interactivity, but
performance is not as good as Inventor (since customization is often done
with a slower language than C++, such as Java).

There, I think I'm through talking about Inventor and Performer now.

Intrinsic Alchemy (www.intrinsic.com) is a scene graph engine developed I
think by folks who worked on or with Performer. Alchemy does specifically
target the game development market. There are versions for Windows and PS2.

NetImmerse from NDL (www.ndl.com) is another example of a gaming scene graph
engine that works on Windows and PS2.

Both of these engines are going to be far more expensive than Inventor or
Performer, but probably offer better performance for games and better
portability options.

Graham Rhodes

>
> ----
> Science being insufficient - neither ancient protein species deficient.
>
> Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> L3Com/Link Simulation & Training (817)619-2466 (Fax)
> Work: sj...@li...           http://www.link.com
> Home: sjb...@ai...       http://web2.airmail.net/sjbaker1
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list