>A typical scene would have the same up vector everywhere.
Well, yes, a TYPICAL scene, like a virtual building tour, would have
consistent up vectors. I'm more interested in atypical scenes.
>This means
>that the viewing angles wouldn't change as you went from floor frame
>to floor frame. For example, going up steps would be just an elevation
>change and not a viewing angle change. If the up vector is constant,
>moving across a tilted plane would be like walking up a ramp. The
>physics of sliding, falling, etc. are left to the browser.
It's starting to seem like maybe we're leaving a little too much physics
up to the browser, if I understand you correctly. What if one browser
implements sliding and another does not? You end up with two behaviors on
the same surface. Ordinarily, I wouldn't mind that, except the discussion
did arise out of the subject of VRML/MUSH-type environments, where I'm sure
users will want thoroughly consistent behavior. (Not that they can be
assured of it. I assume that any browser will have the ability to ignore
things like floor nodes and physics at the user's request.)
>If the up vector changes locally, then moving from one floor to another
>involves a viewing angle change as well as a positional change. For
>example, the floors of the exercise room on the spaceship in 2001 would
>be the inside of a cylinder, with the up vectors always pointing to the
>axis of the cylinder. As you move from floor section to floor section,
>the browser would change the viewing angles so that your head is always
>up and pointing towards the axis of the cylinder.
In other words, the viewing angle is modified by the change in floor
angle. Okay, not bad. I suppose a browser could also have the ability to
anchor the view angle to a given object, so that (to continue the 2001
example) I could fix my 'eyes' on Kaminski's sleep chamber on the other
side of the cylinder and then walk around the cylinder. As I do so, the
viewpoint is always centered on the chamber, and so the view-angle changes
implied by the floors are apparently ignored. That is, they're part of the
calculation, but the user never sees the change.
>With a local up vector, the Moebius floor is not hard. Imagine the
>geometry of a Moebius strip approximated by rectangles. You need to
>have two "floors" for each of these rectangles....
Ah, I see! Each neighbor-link would point to the correct floor node,
thereby avoiding floor conflicts in a given object. Clever.
Also on the VRML list, Daniel Robert Goldman said:
>Perhaps we should think instead of 'preferred pathways,' by which I
>mean a suggested path of travel and (optionally) orientation along
>that path. Such a path could either be a line, or an oriented plane...
Given that you're suggesting creation of a path and optional
orientation, this seems like an extension of the floor-node scheme Jed is
proposing. The only difference is that the path would be (optionally)
invisible. That's fine; nobody said floor nodes couldn't be part of
invisible objects. Semantically, you have a slightly different approach.
Concretely, they're the same thing.
-EMeyer
--- Unstable condition--a symptom of life |Eric A. Meyer (eam3@po.CWRU.edu) In mental and environmental change |Library Information Technologies Atmospheric disturbance--the feverish flux| Software Support Technician Of human interface and interchange- (N.P.)|"What do you think, sirs?" -Joel