Re: TGS driving VRML 2.0?
Jim Terhorst ([email protected])
Fri, 14 Apr 1995 14:18:16 -0600
On Apr 14, 9:28am, Grant Munsey wrote:
> Subject: Re: TGS driving VRML 2.0?
>
> 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!
>
>
> 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.
Inventor engines, though are very intuitive and its easy to build new ones,
and use existing ones. When building Inventor-based applications, one uses
C++ to create new classes of engines. Engine functionality and extensibility
is by no means limited to what one can do in a calulator engine or in
a scene graph description.
>
> 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.
I believe we should investigate the possibility of passing dynamic shared
objects that support custom nodes. I don't know what the facility for
dynamic linking are on the MAC and PC, so i'm speaking here only with
knowledge of unix. The downside of this approach is that you would have
to build a copy for each different architecture you wish to have your
custom nodes viewed on.
We could also provide a facility that loads "dynamic objects" that are
interpreted by an existing interpreter. I'm not sure what the details
of implementation would be, but I really hesitate to add
an entire new language to the defintion without first seeing if there is
a way that we can support custom nodes built with any programming language.
jim terhorst (MountainTop::Computing) [email protected]