I have been following this list with great and sometimes painful interest
from its beginnings. I have been part of small team using Inventor for
the past year to develop a real-time threedee authoring environment which
has grown from an interactive video/real-time 3-D art piece at the Taejon
Expo in South Korea last year. My real obsession in Inventor and any
appropriate OOPS/3-D/meta languages and toolkits is to find the right
tools to develop a network distributed time-stamped global visualization
system. This project has driven me for the past 4 years as I have
educated myself in many aspects of cyberspace application, interface and
environmental issues. Like everyone here, VRMLisms have acted to inspire
and synchronize many of my own baby-cyberspace dreams...
Open Inventor is Inventor 2.0 which is compatible with Irix 5.2 and most
significantly with OpenGL.
"Open Inventor is an object-oriented 3-D graphics toolkit built on OpenGL
that further aids the programmer by providing a 3-D database, built-in
event model for user interaction, and the ability to print objects and
exchange data with other graphics formats."
Inventor 1.0 runs on earlier IRIXes. (The C++ programmer I work with on
our project just successfully fired up some Inventor 1.0 code from last
year in our new Inventor2.0 Irix5.2 platform). In OpenInventor, SGI
Inventor engineers added some significant improvements and tantalizing new
classes and functionality. OpenGL is supposedly SGI's attempt to open
their GL libraries to Sparc and Intel platforms. It does work and exist to
the best of my knowledge on these platforms now but existing GL code needs
to have some function names changed to include the new improved OpenGL
recognizable names. From speaking to some people who have done this, it is
really only a small job for a good text editor. As one SGI developer told
me, "OpenGL is open because it's PC (politically correct) and to make
people want SGI's, (because it'll make them hungry for the hardware)."
Yes, to the best of my knowledge Open Inventor file format is there free
for the using - ascii or binary is ok. This is exactly like Postscript.
SGI would like nothing better than to see Inventor file i/o implemented
widely. Inventor is deep, powerful, inspiring and maybe fun. It is very
well worth looking at a copy of "The Inventor Mentor R(Addison- Wesley
1994 : ISBN 0-201-62495-8 $32). Every Library should carry this book
justlike every library should carry Mathematica books, Adobe's Postscript
manuals and probably Autodesk's CDK manuals (if CDK manuals are available
as free standing publications) and maybe next year's VRML1.0 also. The
fact that these books are published as well written, illustrated
paperbacks indicates to me a reasonable effort to propagate a design
approach into the development community.It's a cheap enough window into a
complex subject embodying several man years of programming torture.
Inventor is already a formidable piece of work, and is well worth some
investigation even if only to act as a structural sounding board. But SGI
is not known for their openness, marketing savvy or willingness to embrace
stable environments. They are good at what they do and arrogant about it.
It's not an accident that one of their founders has finally gotten pissed
off with SGI's own buraucracy and started a new company. First thing he
did was hire some of the Mosaic crew away from NCSA to develop some kinda
thinktank for brewing up VRMLish creatures...
SGI make great graphics hardware and has a dedication to taking their own
dream machine technology and offering it up 18-months later cheaply in
condensed form. Just announced: Reality Engine hardware is soon to be
released on a card.
The lastest salvo in the settop box / threedee gameboy wars is last week's
announced deal with Alias and Nintendo to embed SGI's R4400 MIPS chips and
Inventor technology into that product when it emerges from the vaporous
vat... Now we are talking formidable Hollywood modelling presence,
mega-buck child addiction distribution technology and embeded OODBMS
meta-language run-time scene-description environment. It's beginning to
sound like the right recipe. Alias Power Animator, Power Modeller etc.
already read and write Inventor files as do several other hot SGI
applications including Corphaeus Designer's WorkBench (DesignerUs
Workbench is nice 3-D VR set of applications which use Performer , who is
a Reality-Engine optimized rich cousin of Inventor).
Meanwhile, Portable graphics has embedded OpenGL in a chip which could put
OpenGL and Inventor seriously cheaply into the 60,000,000 PC-rich seas.
PortableGraphics are very keen on Inventor and are making sure their
chipset will run it.
I don't mean to evangelize any of this really, but do check it out. The
earlier debates about minimum platform etc. can be really a dangerous
waste of time.
The syntax, tone and openness of VRML language and vocabulary should not
be inhibited by those considerations. Although 3-D net-ualization is
clearly the prime motivating force here I wonder about 2-D or for that
matter n-D aspects of the specification.
Are audio or still imagery or animation or contextual meta-links not
usefully considered as abstract dimensions for the purposes of language
design and analysis?
My first experience of OOP was using HMSL on the Amiga, written by Phil
Burke at Mills College. (HMSL, Hierarchical Musical Specification
Language/Her Majesty's Secret Language was based upon ODE, an object
oriented Forth extension. It permits real-time probability weighted
interaction between n-dimensional arrays of which the 3 MIDI defaults were
note, velocity, and duration. The non-judgemental open availability of
other dimensions and functions was very provoking to one's normal
assumptions about musical dimensionality and the visual meaning and
representation of these.
Since everyone's needs, perceptions and experience of baby c-space are so
individual it may be helpful to conceive it from a higher level. Dropping
down then to [special case] 3-space or [special case] physical-coordinates
or [special case] virtual coordinates might be more flexibly implemented
without everyone getting their nickers in a twist about which is the right
way to do it. I don't believe there is a right way.
What is going to work is the availability of latteral-thinking design
constructs which permit different perceptions to occupy the same
definition space. Isn't this the problem with net-ualization and
navigation anyway? Sometimes SHAPE and FORM and ORDER are paramount,
sometimes SCALE, DEPTH and TYPE are etc. Would'nt these be useful as
essential primitive VRML terms?
If this is the wrong time and place for this discussion I apologize, but
I'm a bit slow and don't function too well in heavy traffic.
Jason.