Difference between revisions of "General X3D Navigation Behaviors"
(fix tragic typos: dear webmaster - I already was certain that TheLeaders was vandal, so I reverted him already twice, maybe you can give me deletion tool to fight vandals-cause I look here more often) |
(fix typo - I marked all vandals with different methods, please regularly see Special:WhatLinksHere/Template:PURGE updated frequently by me and vanquish all these vandals) |
||
| Line 57: | Line 57: | ||
- Changes current view 'pitch' and 'yaw' to change x,z navigation plane. | - Changes current view 'pitch' and 'yaw' to change x,z navigation plane. | ||
| − | + | - Does not induce a 'Roll' rotation. | |
'''Roll''' | '''Roll''' | ||
Latest revision as of 20:48, 28 May 2012
General X3D Navigation Behaviors
X3D Navigation - Planar and Free
Hello 3D Navigation
This is just intended to be a basis for a recommendation to work on the ISO Standard X3D Navigation standards. As we can easily see, VRML/X3D standardized navigation deals with some very primary yet weakly specified types and utilities. Our X3D helped some with closer definitions and a defined utility LookAt. The current standard needs upgrade because it needs strengthening. Some features that are now proven simple and consistent to describe and implement are missing.
When navigation was originally defined there was hesitation to specify anything too closely. Even though quite advanced navigation styles and techniques for using the available controls of mouse and keyboard were demonstrated, only general and mostly optional recommendations are made. It remains very brave for then but for example Walk type navigation seems not to absolutely require realistic terrain following and collision. This is a signal that not all participating players could do all those things at some time in the past, so the standard was weak.
In general, we want to require names for the minimum number of types needed to navigate in 3D space using the VRML and current X3D standard 'single' input system where only one navigation type can be active at any time. Maybe too bad this is so basic but that is an interface limitation X3D recognizes, you may only be able to do one thing at a time. These basic ones, Walk, Fly, Pan, Roll, and Slide will be sufficient for many needed navigation functionalities.
Next, we can consider some basic automated navigation utilities, Examine and LookAt. Both are needed to take the pain out of mouse-like navigation in the scene.
Finally, with that basis X3D can approach standardization of a terrain following 'game' type navigation. This Play navigation adds capabilities because two inputs are used to define movement rather than one. For example, it is common to control the gaze and thus the general direction of motion along the terrain using the mouse, then control the actual forward, slideleft, back, slideright movements by pressing keys. This is clearly common and may work to enhance other aspects of interactive Web3D.
So, VRML/X3D browser vendors now can all do pretty much the same navigation effects if they want to and have generally all tried to do something innovative and generally offering much more than the standard actually requires. Only problem? Not consistent.
First, there is only so much you can do with the current setup. It is totally composed to operate using a pointing system that operates on relative x,y movement only. I mean that whatever 'navigation' you pick, the movement can only describe changing the viewer position or direction with regard to the single current navigation plane.
As in a movement like typical VRML/X3D 'Fly' using a normal mouse interface, it can work where +y is go forward and +x is go right, there is no way to go "up" or "down" without changing what I called the 'current navigation plane'. In X3D/VRML with the typical setup, to change the navigation plane you switch from Fly to a mode like Pan or Roll or Examine that will allow you to set up that current plane so you can aim at where you want to go. Then switch back to Fly and go forward.
First the fundamental movements:
Walk
- Follow terrain with collision and apparent gravity effect.
- Speed 0 allows rotation of the view around the horizon.
- on current surface. relative +-y controls forward and reverse along path of gaze, relative +-x controls gaze along the current navigation plane.
Fly
- Follow current view x,z surface with collision no gravity effect (except if applied by physics)
- Same as walk, forward, back, rightyaw, leftyaw on current x,z plane.
- Speed 0 allows rotation of the view in any direction.
- Yaw view direction changes must not produce an effect upon the pitch or roll attitude.
Specifically, the gaze direction is the movement direction. The gaze direction is limited to sweeping the current x,z navigation plane.
More Necessary 3D Navigation
Next, some more for what is actually needed to support basic mouse-driven x,y navigation.
Pan
- Free look view direction with view position fixed no collision (Fly or Walk with Speed 0
- look around in any direction +y is up, +x is turn right
- Changes current view 'pitch' and 'yaw' to change x,z navigation plane.
- Does not induce a 'Roll' rotation.
Roll
- Control viewer orientation around view z with collision
- Rotate around viewer z to change current view x,z navigation plane. +x to roll viewer CW.
- Does not induce 'pitch' or 'yaw'.
Slide
- move position relative x,z or x,y with collision
- move right and left (and up, down if Fly) on current view x,y plane to displace current x,z navigation plane.
With these we can actually move around on a surface and even change orientation of the navigation surface to simulate flying, if only in a clunky way. If done right, then you could Pan to pick your relative z direction and pitch, Roll some for orientation, and Fly to go forward and set your relative x,z heading, and maybe Slide to change relative x,z and x,y position. Since VRML/X3D 'fly' with a mouse should allow only yaw turns, you need to switch back and forth between these various navigation types to set your desired pitch, roll, yaw, position, and direction.
So, these five Walk, Fly, Pan, Slide, Roll, are the basic movements for mouse-type surface/point movements in this type of one-input navigation control scheme. Every truly X3D Web3D browser should do all of these and call the same the same.
As well as a typical looking context menu list, uniform keyboard keys must allow easy ways to select/change any navigation type.
In all cases a uniform way to allow select 'mousedown' for navigation, both for movement and for LookAt, without activating underlying touchsensor/anchor nodes must be provided.
The arrow keys must be defined consistently with expected mouse operation in the current mode.
Universally, Shift for faster movement.
It is most fun to be able to hold the mousedown while switching modes without halting and manually restarting the movement.
Navigation Utilities
Navigation utilities are added to ease the pains of mouse-only navigation.
Examine
- Change the view to orbit an object of interest with respect to a defined centerofrotation with collision.
- active pointer motion causes the position and orientation of the view to move with constant radius around the centerofrotation while maintaining the gaze aimed at the centerofrotation.
LookAt
- Allows the user to point at and select an object of interest.
- Moves the viewpoint closer to the object, sets a new centerofrotation based on the selection, and aims the gaze upon the new centerofrotation.
The current navigation plane must not change its 'up' during LookAt. That is, only pitch and yaw are changed to move the view, not roll. The navigation type must not change by selecting LookAt. All sensors active during movement.
Uniform method of selecting and activating the LookAt operation without changing the navigation type is required.
Effective method of switching between Walk, Fly, Slide, Pan, Roll, Examine is required.
Note: The spec statement with navinfo "... if content specifies both "LOOKAT" and "EXAMINE" types, any "LOOKAT" operations shall change the center of rotation for subsequent "EXAMINE" operations." is wrong, because there are no conditions. Selecting an object for LookAt should always reset the current view centerofrotation based on the latest selection.)
That about does it for this kind of primary mouse-driven navigation. One opportunity? Is it still too soon to think that a standardized user would have a pointing device with at least three ways to make it active, plus at least one wheel?
Stand Together
I pause here only because these navigation types and utilities capture what is already proven in VRML and X3D content, cumulatively by many different browser implementations. Here the X3D browsers must stand together. There must be standard, simple, non-optional but user-settable controls for these simple yet necessary navigation features. Further, these form the basis for author control of more complex tour-type user assisted navigation.
Now for some Actual 3D Navigation
As a next step, realistic navigation requires that more than one of these navigation modes are active simultaneously. In a vernacular, this means at least two navigation vectors are active: gaze and movement. The direction of movement is derived from the gaze direction.
One great success for terrain navigation is the idea of using one set of keys for forward, back, slideleft, slideright movement and another set and/or the the Mouse for gaze and movement direction. The effective mouse pointer position provides the gaze direction, along with x and z reference for the movement directions. When you select forward, you go where you are looking, and you can slide right and left relative to your gaze.
Play
- Free gaze direction by mouse pointer, like Pan, +y moves gaze up and +x moves gaze right.
- WASD keys provide direction control for movements forward, slideleft, back, and slideright.
At this time, this type of interface is well enough proven to standardize as a Play navigation mode. Does any browser maker have a problem implementing gaze tracking the mouse? Any Problems using WASD keyboard for forward, slideright, back, slideleft?
Since this mode requires several controls just for movement and because several more features may be added to accomplish other play iteractions it is unclear what to recommend concerning other shortcut controls of the X3D browser and supporting platform. This needs a write up.
What About Free-Flight?
X3D Standardization of free flight navigation is not necessary at this time. To change direction, we use instant combinations of pitch, roll, and yaw plus forward, back, slideleft, slideright movements. For now, this is all best done by connection of an appropriate controller. Some flight controls using multiple sets of keys and mouse are seen but are not satisfactory and thus not necessary to consider. Maybe you can steer free flight with only mouse and roll. who cares, gimme the joystick and keyboard and it is done.
Conclusion
Navigation is complex. Every application has differing but common requirements. When movement is required, the author must be able to offer satisfactory solutions. The above analysis and comments comes from the best I have seen and needed. These six basic movements here named Walk, Fly, Pan, Roll, Slide, and Play plus the two utilies LookAt and Examine will provide the basic tools needed to provide performant navigation and an outline for updating the X3D standard.
there is a partial attempt in the x3d standard to help define some interactivity, at
