Len sez:
> I'm not sure we can always smooth over "physical" transitions like
> loading a new world.
I think one of the lessons learned from VRML 2.0
is that giving the browser rather than the author
control over loading and unloading objects is a
bad idea. The GeoVRML people are especially
sensitive to the unloading problem, since no
VRML browser I know of actually frees memory when
you removeChildren, and they're talking huge
data sets.
And I think we add so much to VRML if we let
authors determine when and how to preload worlds.
I still think of the vision Sam Chen shared
with us of starting the visitor inside a room
while the nearby scene is loading, then as
the visitor walks along the path, the objects
in front of her load and perhaps the objects
two stages back unload. This is *almost* doable
right now with standard sensors, but of course
the unloading problem will eventually bite
anyone who stays in a world too long.
> Outside of using Java or a cookie, I don't know
> how we use web apps for persistent value storage and
> passing between the worlds unless we do it in HTML.
> I don't think that is practical but I could be wrong. For
> very complex stories, I think we would find ourselves using a
> database.
Daniel Lipkin has convinced me that even for the
simplest worlds that have persistent states, a
database is highly appropriate. Now in the
simplest example, a book on a table which a user
moves to some other location on the table, a
database seems on the surface to be an absurd
place to be storing 32*2 bits of information
(assume Y is constant) plus maybe another 16
bits for a user ID, but the infrastructure
you'd need to do it any other way is mind-boggling.
For example, how many people really want to write
sockets? Not to mention locking and semaphores.
In return, I think I've got Daniel more or less
convinced that, while the current primitives are
fine to demonstrate basic functionality, we need
at least one more layer of abstraction. Authors
need to be able to think in terms of objects and
defined areas of persistent variability for those
objects. They don't need to be thinking about the
procedural means for accomplishing the reading
and writing and signaling.
Sorry this was so unliterary, but when the time
comes, I think we need to start speaking up
about how VRML should change to accommodate
some of the things we need.
And in keeping with the off-topic nature of this
posting, I commend your attention to:
http://home.hiwaay.net/~crispen/vrmlworks/faq/
Two people who are not in the spotlight by any
means, Hendrik Reichel and Yukio Andoh, have
translated the comp.lang.vrml FAQ into German
and Japanese respectively.
When I consider the simple generosity of that
act by each of them, I'm honored to be a small
part of the VRML community.
--
Rev. Bob "Bob" Crispen
[EMAIL PROTECTED]
Music shouldn't be held responsible for the people who listen to it.
