Re: TGS driving VRML 2.0?

Grant Munsey ([email protected])
Fri, 14 Apr 1995 09:28:11 -0700


I think that TGS is not "driving the 2.0 standard along willy nilly" so
much as voting for what they already have in place ... Inventor. All the
stuff they have shown is functionality right out of the Inventor Mentor
book and is in the source that SGI licenses as far as I know.

I think the real question is if Inventor 2.0 with slight mods should
be VRML 2.0. After all VRML 1.0 is really just a highly scaled back
Inventor with a couple of new nodes.

You can always come up with stuff that is wrong with IV 2.0 but after
15 years of using different 3D formats of one kind or another I find
the geometry definition part of Inventor pretty good.

The question now, I think, is should we just go ahead and say ... Inventor
2.0 is pretty good lets just use it all. It does have the advantage
that there will quickly be a browser base since none of the Inventor
licensees have to do much to implement 2.0. Another advantage is that
many of the browsers will work the same ... since they are really the same
code!

I have a slightly different twist on 2.0. I would really like to see
the rest of the geometry definition nodes from Inventor put into ...
maybe VRML 1.1 or some such. I find the geometry definition parts of
Inventor to be quite reasonable and would love to finally see some
3D format that could take over from ... shudder ... DXF as common
way to ship around 3D shapes. This is the area where I think that
the SGI has a lot of experience that they brought to bear when they
designed Inventor 2.0.

However, I don't think SGI had all that much experience to draw on when
they designed the behaviour stuff. To me it has the flavor of a strained
paradigm.

In past designs I have always gotten myself into trouble when I wanted
programmability but didn't put in place a full blown programming language
to support it. Currently this is how I view the "programming language"
that Inventor 2.0 has.

I would much more like to see Java used to provide a machine independent
programming language for behaviors. Even scheme would be comfortable enough.

I think a good thing to remember is that we are not really going to have
the luxury of adding new node types when we come up with behaviors that
can't be "coded" well in the programming language we put into VRML so we
better put in a language that is pretty general.

Cheers,

Grant J. Munsey, Cognicon Inc
(408)252-1135[voice], (408)446-9355[fax]
[email protected], http://www.rahul.net/grant