> Nathan comes up with another interesting idea:
>
> >Using the extensibility method in the SPEC I think we could add
> >a method for describing new nodetypes. We would need some way
> >to represent variables.
>
> I wouldn't use the word "variables"; indeed, that confused me quite
> a bit when I first read this message. Actually, your example is
> showing (essentially) the notion of adding new *classes* to VRML,
> and *parameters* to those classes:
>
> >NEW IceCreamCone {
> > fields [SFFloat radius %rad, SFFloat height %hi]
> > TransformSeparator {
> > Sphere { radius %rad }
> > Translation { translation blahblahsomenumbers
> > rotation blahblahsomenumbers
> > }
> > cone { bottomradius %rad
> > height %hi
> > }
> > }
> > }
> >CUST IceCreamCone {radius 2 height 3}
>
> Not a bad idea; it's a rather simple, elegant way of coming up with
> parameterizable compound objects. (I don't like the "NEW" and "CUST"
> keywords much, but that's a detail.) I'd love to get an opinion from
> folks like Gavin and Kevin, who have presumably done a fair amount
> of node extension in Inventor, on what strengths and weaknesses they
> see in this idea. (This seems somewhat related to the Inventor Node
> Kit concept, but my understanding of how that works is still a bit
This direction is interesting, but I think the motivation for doing
it needs to be examined. VRML is not supposed to be an authoring
language or a programming language. It is primarily a data format.
Making life easier for people to hand-edit VRML files should not
be a priority.
Adding parameterized meta-objects (like the IceCreamCone) to VRML
will make parsers bigger and slower. Authors who create scenes
with interactive graphical programs (i.e., the right way :-> )
will never see any advantage caused by this addition. Neither will
anyone browsing worlds. So why add it (or other programming-language-
like features) to the language?
-- Paul S. Strauss [email protected] Silicon Graphics Computer Systems Open Inventor Web info in http://www.sgi.com/Technology/Inventor.html