>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.
>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.
Ah... This makes sense; characteristic behaviors is exactly what I wanted
to separate from the spacial issue.
> > 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 ?)
Ok. My terminology here was lacking. By the spacial aspects, I mean only
the spacial relationship between objects in a common coordinate system. In
the above paragraph, defining the space and spacial aspects are the same
task, it's defining characteristic behaviors and navigation modalities that
I feel is separate from the establishment of spacial relations.
>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.
Space description could simply be cartesian coordinates and a solid angle
rotation orientation, telling you nothing about behaviours and navigation
>BTW you still have the factor that in one sense *motion* is a temporal
>measurement of *space*.
Yes. That's why VRML should address motions/behaviours, etc. But defining
those motions is a different question than defining the space. But vital
to defining a *scene*.
>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.
Yes and no. I am coming from the perspective of semantics, as I'm not well
versed in common solutions to the various problems of simulation, but in
simulating the space, we are talking about behaviours. As long as I know
the relation of the objects I can create a window into the space and look
around. My 'zoom' factor may need to be adjusted because I don't know what
a meter looks like, and my orientation may need some rotation to line my
"up" with the author's intended up, but the space exists and I can model
it. I just won't be interacting with it in any way the author intended.
> > 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.
After reading your post, how do
Viewer Behaviors, Spaces, Object Behaviors, and Control Behaviours
work to describe the four concepts I was trying to isolate? I guess I
still like motions, spaces, behaviors, and controls. That seems to better
delineate between different behaviors of objects in the space.
I guess where I got started here is that x,y, and z have been addressed as
navigational, spacial, and client-view issues. The spacial issue should be
internally decided by the author. Navigational modalities should allow the
author to define characteristic behaviours - hopefully ones both common and
uncommon - so we should establish a few solid ones. And client-view issues
- "Z points into the screen" - are not the duty of VRML IMHO.
As an author, I shouldn't care which way Z looks to the viewer, but I
should define that 'walking' means unit translations, or steps, of 1 unit
(meter) along the x,y plane (or whatever plane I want) in the direction the
viewer is facing. Now you can walk around my space, because I defined what
it means to walk.
I'll try to find Benedict's Cyberspace and see if that helps me get a grip
on some common terminology. Meanwhile, Let's pick some modalities and
define them. Identifying an explicit modality could help us identify some
language needs we haven't touched on yet.
Joe Andrieu email@example.com