Re: A full-fledged VRML proposal

Paul Burchard ([email protected])
Thu, 15 Sep 94 01:52:33 -0600


In http://www.wired.com/vrml/oi/VRMLDesign.html
"Gavin Bell" <[email protected]> proposes:
>
> A node given a name using DEF may later be instanced by the
> reserved token USE followed by whitespace and the name of
> node. If several nodes were given the same name, then the
> last DEF encountered during parsing "wins". For
> example, rendering this scene will result in three
> spheres being drawn. Both of the spheres are named 'Joe';
> the second (smaller) sphere is drawn twice:

>

> Separator {
> DEF Joe Sphere { }
> Translation { translation 2 0 0 }
> DEF Joe Sphere { radius .2 }
> Translation { translation 2 0 0 }
> USE Joe
> }

Are name-bindings in Inventor "scoped" by the hierarchy, like
properties, or global? (Your example indicates that bindings are at
least context-sensitive.) 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.

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.

Scoping has the advantage of reducing name clashes when scenes are
composed from multiple pieces, but it seems that for API purposes
there needs to be some way to refer to instantiated objects that are
not defined within the current hierarchical scope.

> 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.

> 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?

--------------------------------------------------------------------
Paul Burchard <[email protected]>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------