From: Bob Crispen (crispen_at_hiwaay.net)
Date: 22 June 1998
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
crispen_at_hiwaay.net
Music shouldn't be held responsible for the people who listen to it.
This archive was generated by hypermail pre-2.1.8 : 28 November 2004 CST