> The entire world will be stationary with a fixed light source. I know
> this is early days, but I'd like some thought put into being able to
> *see* gophers, agents etc shooting off at the user's behest. This is a
> client thing I know, but it would help I think.
This reminds me of what I think is the really crucial (and difficult)
aspect of designing a vrml: getting the level of abstraction right.
It's very easy to want to specify too much, to have an image in
your head (in your world) that you want others to see. This is
analogous to being able to specify italics and bold in html; you
can do it, but the preferred option is to have <em> and <strong>,
and let the user tailor these as they wish.
WRT the above, some people may want a 2D world and others may want
3D; some may want a fixed light source, and others may want it to
move. Within the space, some may want a floor/ground, and others
may not want to be constrained in that way. When you create processes,
some may want to see them and others may not (some will want the
feedback and reassurance that they're actually going, while others
would live in a world with so many of these things that they would
just clutter things up).
I get very worried when I see descriptions in terms of particular
polygon shapes; suppose I want mail messages to be spherical,
newsgroups to be 2D pages, webpointers to be arrows, and programs
to be rectangular prisms; while other people would prefer different
conventions, just as people like different fonts. The thing to do,
I think, is to try to characterize the kinds of processes/objects
people will be manipulating, and just transmit their names in the
vrml; if the client doesn't have any shape for a given name, they
can of course request one from the location the shape resides in,
and use that as the default until/unless the user decides to
change it. [Laziness will ensure a high degree of compatibility
in overall layouts, I'm sure.]
> ... The VRML could contain hints as to how the
> client should present the link to the user (as a stair, path,
> highlighted text etc). This way all users would see the same physical
> scene, but if different users see different types of connections
> between scenes, does that really matter?
Does it matter if they see different physical scenes, as long as
the connections have the same structure?
> If the link were represented
> depending on vague parameters within the scene (like a book on a
> bookshelf may have a link that is a hole in the ground that you jump
> into, but a fence with a link in it would be a gate), automatically by
> the client, then a change in the scene would (possibly) change the
> link, alerting users to modifications of a VRML document.
Things I think it's important to be able to put into a link is
how much stuff there is at the far end, and how far away it is
(in terms of time to get there and back, and bandwidth). it
continually happens with html that as soon as you realize it's
going to take ages to get a document, you kill off the request;
it would be better if you could tell ahead of time (which is
why some directories have a practice of putting the number of
bytes beside entries).
> Also, the examination and navigation of a 3D scene is non-trivial and
> takes considerably more time than examination of a text document.
> A 3D scene can contain much more data but just how much data is in one
> HTML document at the moment? If one were to enter a scene with
> hundreds of links, then the design of the scene becomes crucial to
> allow easy and efficient access to the data and links so that users do
> not waste their time or miss important features/links.
This is important. When you go into a room/space, you might see
a bookshelf, but not necessarily the individual books. You get
closer and can see the titles. Then you open a book and jump into
it, seeing its contents a la The Never-Ending Story. This has to
appear smooth and reasonable; so requests for details have to be
sent during navigation, and the appearance of details should
avoid the sudden jumps you get with gifs in mosaic. A tricky
problem (that I don't know how to solve).
------------------------------------------------------------------------------
[email protected] ftp://tuda.ncl.ac.uk/pub/local/ncmh1/nameplate.html
------------------------------------------------------------------------------
I had rather be a dog and bay the moon, / Than such a cybernaut.