>Units of Scale & Orientation -
>
>To avoid disorienting situations, like grabbing someone's "telephone" object
>and finding out (the hard way) that it's two stories high in your view of
>the world, it was agreed that a common unit of scale and orientation (how
>big is big and where is up) would need to be defined. These are
>conventions, in the sense that they need never be passed by VRML as a
>message, but they need to be coded into the browser at a very basic level.
I'd suggest that the standard units be "real" ones; eg, meters. (Not that
I'm especially fond of the metric system, but it *is* easy to compute with.)
Pick some standard unit that relates well to Real Life...
(We should seriously consider, BTW, the merits of a "units" command in
VRML, to make it easier for people to design really small or really
big things. Probably not necessary, since I suspect most design will be
done through tools, but it might be nice...)
>URL "Anchorage" -
>
>We should be able to attach a URL to any object or sub-object in a
>hierarchy. Don Brutzman came up with a truly EXCELLENT idea, which gives us
>some of the features of behaviors for free; attach MULTIPLE URLs to an
>object and fire them off, in any order desired when an object is "opened".
>Thus, clicking on an object could 1) reposition a camera, 2) play a sound,
>3) bring up a web page, 4) whatever... The consensus was that this was a
>_very_ good idea and should be part of a VRML 1.0 specification.
This is definitely a good idea, and a point that might have been
overlooked. One more thing to bear in mind: when we do add behaviours,
we will probably need to add different URLs particular to specific
behaviours. We shouldn't do anything to close off this path...
>Cameras -
>
>There needs to be a "camera" construct in VRML, perhaps multiple cameras
>(which allow for stereo views of scenes, for those who have the rendering
>speed and the output devices).
Do you think that the designer would specify both cameras for the
bifocal view? I'd always figured that only a single "camera" would
be specified, and the bifocal browser would automatically create two
views slightly offset from that...
I do think that multiple cameras are a good idea, but I'd generalize
the mechanism a little. What we need to specify in the language isn't
exactly where a camera *lives*, but where it *starts*. As the user
wanders around the room, the camera will be moving. The reason to
allow multiple cameras (preferably named) is to allow multiple entry
points into the room -- the initial camera view may depend on how you
enter...
>Messages -
>
>Mark Pesce explained that Labyrinth, his VRML browser, could "listen"
>to messages sent to it from other applications; in a manner similar to, but
>more sophisticated than the "remote control" features of the Motif versions
>of Mosaic. Thus, a "helper" application could direct or control Labyrinth's
>behavior. This seems to be a natural way to get interaction between
>applications on a user's desktop, so the group attempted to define some
>messages which a VRML browser could choose to "receive" and act upon. The
>three which seemed the most important were: 1) the ability to change the
>position/orientation of a camera within a given scene; 2) the ability to add
>a new instance of a given object within a scene; 3) the ability to remove an
>instance of a given object within a scene. 2) and 3) are predicated on the
>supposition that objects are "defined" in one stage, and "instanced" into a
>scene in a separate process, rather like the OOP concept of a class
>definition and an instance of an object of that class. Peter Kennard
>noted that a simple, repeated Add/Delete sequence could give a very crude
>animation capability to VRML 1.0 compliant browsers.
Interesting; my immediate reaction is that there should be a fourth
option, to *alter* an object in the scene. This would allow a much
more natural mode for animation, it seems to me, and shouldn't be all
that hard if we're allowing object creation (which means we already
need a way of specifying field values). Seems to me that this would
be *enormously* powerful, providing essentially the API/user language
capabilities we've been talking about, without a heckuva lot of added
difficulty...
(I think that there's a fair bit of consensus that there should be
*some* mechanism for outside programs to affect the state of the
display; the only big question is how they interface...)
-- Justin
Random Quote du Jour:
"The paper
Piety
The artist
Anxiety
And sensing a win
for inanimate things,
The rug
looked smug."
-- from "Cages"