At first I thought you were saying that the *whole_ball_of_virtual_wax*
wasn't a space issue.
But since you identify the *space* as such, I think what you are talking about
is a navigation issue. More to the point you, are identifying the navigation
modality as the issue in question.
> However, defining Characteristic Motions could add significantly to the
> usability and friendliness of a space. I think it'd be a good thing to
> identify the Characteristic Motions a space should/could support - walking,
> jumping, flying, etc., and possibly define some defaults in terms of the
> default unit (meters or whatever). Then, if I have a client that supports
> a walk around mode, I can 'walk' through a space and move through the room
> as the author intended. "Wow, walking through this room is like being on
> the moon..."
Perhaps it would help to think of this aspect as a question about
characeristic *behaviors*, which could vary or remain constant across a
set of navigation modalitys.
>
> But I think this is quite different from defining the space. It's defining
> motions, which is something we should deal with, but IMHO it should be
> separated from the spacial aspects of VRML.
I really don't see how you seperate the "spacial aspects of VRML" from
"defining the space".
(VRML is to be a space description language, is it not ?)
defining motion of navigation is a behavior issue, as I have pointed out,
I know that it has been also called a *scene description language*,
but since VRML is basicly 3D, I think that *Space description* is best.
BTW you still have the factor that in one sense *motion* is a temporal
measurement of *space*.
> >Since VRML will have general modelling transforms, you will have the
> >freedom to do what you want to do. Since VRML cameras will have
> >look-at point, camera location, and screen up directions, again, things
> >are OK. But the fact that the camera is lying flat on its back,
> >staring into the sun does not mean that camera up is the same as
> >world up.
> Yes. But that only matters if my motions are to be specified by the
> author. If my body is that of a bumblebee, "flat on my back" isn't really
> an imporant concept, since I won't be walking like a human anyway.
all the more reason to have a cohesive abstraction based on common concepts
of axis, and orientation.
I understand the desire to have flexibility in local implementation of the
abstractions, VRML should not be so inflexible that developers and designers
have no flexibility in their applications *charateristics.
>
> >Similarly, If someone gives me a "cool picture of a ming vase",
> >how big can I expect the vase to be? 1 unit? 1000000 units? Thus,
> >Its nice to agree on the size of a meter, and which way is "up".
>
> I agree with specifying a common distance measurement. And within an
> object, VRML should prolly specify which orientation is default for
> invocation - so I can call an instantiation of a Painting and expect to see
> it right side up and facing me.
> But a _space_ defines it's own up and down in the relationship of the
> objects. If the sun is "up" and I'm lying on my back at a particular entry
> point, "up" is only relevant if there is gravity or some other factor
> affecting Characteristic Motions. If that same world were weightless,
> where 'walking' is a strange concept, "up" is not very usefull.
I really think that you are pointing at the semantics of space, and what
is at issue with unit of measurement and orientation standards is the
simulation of space. You don't need them ( Units and orientation) to
talk *about* the space ( semantics ), but you do need them to simulate the
space and interact with the space.
> I'd like to separate motions and spaces, just as we want to separate
> actions and controls. (motions here means viewer/camera movement, while
> action is object activity). Motions describe client movement through the
> space; spaces define the relationships of objects in a cartesian coordinate
> system; actions define the object-initiated manipulations of the space; and
> controls define external manipulations of the space (whether initiated by
> server, client, human, or agent). There may be better words or
> definitions, but I think at least three of these isolate areas of VRML we
> should approach with awareness of their distinct natures.
>
> Does this breakdown of things in VRML make sense?
we desperately need to start defing terms, and sifting through the jargon-heaps
or we will continue to spin wheels on semantics IMNSHO.
LUX ./. owen