They're global.
> (Your example indicates that bindings are at
> least context-sensitive.)
Well, you can't USE something before you have DEF'ed it, and if there
are multiple objects with the same name the last one DEF'ed will be the
one a USE refers to.
> Is the lifetime of a name-binding limited
> to a single scene? If everything is scoped and expired, how can a
> script (or link to a script) located in a one part of the hierarchy
> manipulate or redefine a named object in another part? I'm not sure
> I see the necessary power here for producing a scripting API.
The lifetime of the name-binding is the same as the lifetime of the
object. The binding is destroyed when the object is deleted. Inventor
punts on dealing with multiple objects with the same name-- methods are
provided for either getting the last object given the name, or getting
all objects with a given name.
> In apparent contrast to Inventor, OOGL uses a model of instantiation
> with global, persistent, referentially transparent handles (so that
> redefinitions of a symbol update all references to it, including
> earlier ones). This model has proved to be very useful for external
> program control. For example, redefinition of instance handles
> serves as a general, efficient mechanism for remote/external scene
> manipulation. In addition, persistence of handles across scenes
> provides a way to cache frequently reused objects in memory from
> scene to scene, effectively providing customized "built-in" objects
> for use in a series of scenes.
Could you give a for-example for these? I'm pretty sure you could
build a system on top of Inventor's naming scheme to do all of this:
-- re-define object currently named Joe to be a Sphere { } is easy--
just search for nodes named "Joe" in the scene and replace them with
the new sphere named "Joe". If you're using the Inventor library, the
act of replacing a node in the scene with another node will
automatically cause it to be deleted when the last instance is
replaced, getting rid of the old binding of "Joe".
-- you could assume that all objects named "Refrigerator" are the same;
when reading in a new scene, replace all new objects with the name
"Refrigerator" with the built-in Refrigerator. That seems dangerous to
me-- a cache based on WWWFile nodes seems much more useful in the VRML
context (you can automatically instance WWWFile children if they have
the reference the same URL).
-- you can also build hierarchical names on top of Inventor's simple
naming scheme-- a name like "Joe.Bob.Toe" refers to the object named
"Toe" underneath the object named "Bob" underneath the object named
"Joe". This isn't very hard to implement if you DO want scoped names.
> > Issue: Orthographic views are very important for some
> > application areas (molecular modelling, some CAD). Is
> > it important that the first release of VRML support
> > these?
>
> I say yes. Orthographic perspective is useful for a wide variety of
> application areas -- anywhere the precise alignment of objects is
> significant. Also, it is not particularly difficult to implement.
That's two votes for it (one of the members of the Inventor group felt
it was important, too). Implementing the rendering of orthographic
scenes is trivial. Implementing user interface that can deal with
either orthographic or perspective scenes is the hard part. Anybody
want to vote against orthographic cameras?
> > Issue: Should conventions for the information inside
> > Info nodes be established to allow browsers to interpret
> > that information? For example, the convention for
> > author information could be a line of the form "Author:
> > author_name".
> If so, we should definitely use an existing meta-info format. Maybe
> even HTML?
A very interesting idea.