alfu
November 2nd, 2009, 04:30 PM
I have always been frustrated that even in premier graphics programs, a selected virtual object (selvob) moves off-screen when the view is zoomed in. I have recently seen YouTube videos of the spectacular window transforms that Ubuntu/Compiz Fusion can do. I think computers are now fast enuf, and screen real estate finely grained enuf that we start exploring the user experience affordable with self-centering selvobs.
Sphericity, proximity and fluidity give an eye its speed
The best computer interface pointing devices exploitable under current technology are user's eyes, because they are the fastest, most finely motile human effectors and they innately indicate the user's interest.
1) Like wheels, galaxies and vortices, eyes derive a most natural motion by superposing pivot and center of mass. Crankshafts of high-performance motors, tied to linear actuees (pistons), are meticulously balanced to yield speed because they have pivot/mass dissonance to overcome. Computer mice, also linear actuees on the end of arms, must also overcome this limitation.
2) Nerve impulses communicate with the eye quickly since it is the brain's closest effector.
3) A portion of the eye's mass need not be overcome in panning since it is filled with fluid which is not locked rotationally with the eye's shell.
Mice and keyboards are too slow. If a user mouses a curser to screen locus §, it is only because s/he has already been looking at §, searched for and found the cursor, and then wrestled the cursor to §! It could already have been there!
Other modalities like voice interaction technology will probably never be useful as navigation tool, altho it may be OK for dictation. Datasuits and derivative devices will be limited to the high end, due to average user's dislike for changing clothes as well as cost. And direct electrodes to the brain are a little kinky for general acceptance just yet. Gaze evaluation technology (GET), however, not yet used cybernetically but well established in psychology research labs, can incorporate into binary head-mounted video displays (bivids). GET promises computer usage without training due to gains in intuitiveness, and could supplant the mouse as a pointer for the "rest of us" in a manner almost free to the end product bivid, if not to development.
The eye's cornea is a smaller spherical bulge from the eye's main sphere, so a collimated beam reflecting off it deflects as the eye rotates. Similarly, an optodetector will develop a pulse output at varying times if a swept beam, as generated by a scanned display device, reflects off the cornea onto its surface. By stringing together time delay data supplied by three optical detectors located at vertices of a triangle in a similar plane to the LED array, a counter can generate an address to fetch the X and Y gaze coordinates.
Miniaturized, headmounted, LED scanned virtual screens are now available to the end-user, and are well on their way to going stereoscopic. A somewhat larger leap is required to see how they will absorb GET. GET has long been available to psychological researchers, but never as free as scanned LEDs potentially offer it, and not yet integrated in a virtual display device.
OK, I've got my hands tied behind me and I invite you to join me to "virtually" explore some beginnings of what eyes can offload from other vias.
First we notice the cursor disappears. It exists wherever we look, so there is scant reason it actually be visible.
Second, little glittering sputniks cross the screen at random. Everyone's eyes are different, and the computer knows you will look directly at these sparkles. What it is doing is building a lookup table in memory of gaze coordinates to see if it recognizes your ocular signature. If it doesn't, it will request a logon. No password required: your eye movements uniquely identify you.
Third, you notice that if you stare at an object for more than just a little while, it becomes selected, subject to whatever you do with other input vias. To deselect it, you simply look away. You don't even notice at first, but then realize whatever you look at pans toward the center of the screen, as if you had turned your head toward it, at a rate proportional to the log distance your gaze is to screen edge. All you have moved is your eyes, and the computer even keeps moving those gently back to axis.
A little colored sphere hovers near your gaze, but like a biological 'floater' in your optic fluid near the retina, it keeps out of the way. You have to glance at it quickly to really see it, but when you do, it opens up into context menus.
GET in 3space
Datasuits have never gone mainstream, due to their inherent realtime lag, expense, complexity and incovenience. In the real world, we perceive things and then we move our bodies to pan so we see them straight on. For user comfort, but more for computer speed considerations, selected virtual objects (selvobs) should self-align toward 2space window center, regardless of the interface modality, to realign selvobs with the resting axis of the eye. Since the 2space window representation of virtual 3space (v3space) realigns at its own rate, user disonance derived from perceived lag with head position detection technology does not exist. The lag perception for panning off-screen would be similar to the perception of the delay in moving the physical body to align with a viewed real object, and this is a perception that has already been incorporated into our daily experience. This automates user panning in 3space, since the user's virtual body representation (veebod) follows the eyes.
Similarly, zooming the veebod can be automated by moving toward a selvob at a log rate determined by the vdistance from it and the eye activity with which the user looks at it. The veebod would not be drawn to non-editable virtual objects (vobs); they would exist largely for frame reference. If the eye is fairly still, it is apparent the user wants to take a closer look, in which case the veebod moves in for more detail. But if the user's eye is sweeping out fairly large segments of vspace, the computer can be fairly certain the user doesn't want to move in closer, and may even want to zoom out for an overview.
Datagloveless selvob rotation is an interesting problem I think can be resolved simply by seeing a selvob off-center. This would rotate vspace (and your veebod) around the selvob so your gaze always rests on its center. The concept is really simple: whatever you are looking at comes front and center so you can see it most clearly. If the selvob were another user's avatar, that person would see your avatar moving around them on an arc. If that person were interested in seeing the side or back of your avatar, the two avatars would be in mutual orbit, with the vworld spinning around.
In modelling 3D assemblies, or in looking at files in folders, it is often useful to explode objects to see a vob's innards. Here, blinks are useful as mouse-clicks. It is a fairly trivial to train the user to blink while viewing inactive screen real estate if no action is desired, but in vspace if a selvob is double-blinked, it could ungroup. Later, when its part coordinates fall out of the 2space window (the user is otherwise entertained), its disembodiment attribs could be cleared, and it would re-form as an assembly.
Obviously, we don't have the GET headsets yet. But I don't think it takes a lot of imagination to see we can already start working on a self-centering cursor by integrating it with existing mouse manipulation. I saw a movie a long time ago featuring a text processor running fast on an Apple ][ -- the text insertion point locked to the middle of the screen and the entire text page moved around that point!
To summarize, we have moved thru vspace toward objects of interest, rotated and disassembled them, all without hand motion. I challenge you to see how much richer our explorations of v3space can be with the datagloves tied behind the backs of our veebods!
Sphericity, proximity and fluidity give an eye its speed
The best computer interface pointing devices exploitable under current technology are user's eyes, because they are the fastest, most finely motile human effectors and they innately indicate the user's interest.
1) Like wheels, galaxies and vortices, eyes derive a most natural motion by superposing pivot and center of mass. Crankshafts of high-performance motors, tied to linear actuees (pistons), are meticulously balanced to yield speed because they have pivot/mass dissonance to overcome. Computer mice, also linear actuees on the end of arms, must also overcome this limitation.
2) Nerve impulses communicate with the eye quickly since it is the brain's closest effector.
3) A portion of the eye's mass need not be overcome in panning since it is filled with fluid which is not locked rotationally with the eye's shell.
Mice and keyboards are too slow. If a user mouses a curser to screen locus §, it is only because s/he has already been looking at §, searched for and found the cursor, and then wrestled the cursor to §! It could already have been there!
Other modalities like voice interaction technology will probably never be useful as navigation tool, altho it may be OK for dictation. Datasuits and derivative devices will be limited to the high end, due to average user's dislike for changing clothes as well as cost. And direct electrodes to the brain are a little kinky for general acceptance just yet. Gaze evaluation technology (GET), however, not yet used cybernetically but well established in psychology research labs, can incorporate into binary head-mounted video displays (bivids). GET promises computer usage without training due to gains in intuitiveness, and could supplant the mouse as a pointer for the "rest of us" in a manner almost free to the end product bivid, if not to development.
The eye's cornea is a smaller spherical bulge from the eye's main sphere, so a collimated beam reflecting off it deflects as the eye rotates. Similarly, an optodetector will develop a pulse output at varying times if a swept beam, as generated by a scanned display device, reflects off the cornea onto its surface. By stringing together time delay data supplied by three optical detectors located at vertices of a triangle in a similar plane to the LED array, a counter can generate an address to fetch the X and Y gaze coordinates.
Miniaturized, headmounted, LED scanned virtual screens are now available to the end-user, and are well on their way to going stereoscopic. A somewhat larger leap is required to see how they will absorb GET. GET has long been available to psychological researchers, but never as free as scanned LEDs potentially offer it, and not yet integrated in a virtual display device.
OK, I've got my hands tied behind me and I invite you to join me to "virtually" explore some beginnings of what eyes can offload from other vias.
First we notice the cursor disappears. It exists wherever we look, so there is scant reason it actually be visible.
Second, little glittering sputniks cross the screen at random. Everyone's eyes are different, and the computer knows you will look directly at these sparkles. What it is doing is building a lookup table in memory of gaze coordinates to see if it recognizes your ocular signature. If it doesn't, it will request a logon. No password required: your eye movements uniquely identify you.
Third, you notice that if you stare at an object for more than just a little while, it becomes selected, subject to whatever you do with other input vias. To deselect it, you simply look away. You don't even notice at first, but then realize whatever you look at pans toward the center of the screen, as if you had turned your head toward it, at a rate proportional to the log distance your gaze is to screen edge. All you have moved is your eyes, and the computer even keeps moving those gently back to axis.
A little colored sphere hovers near your gaze, but like a biological 'floater' in your optic fluid near the retina, it keeps out of the way. You have to glance at it quickly to really see it, but when you do, it opens up into context menus.
GET in 3space
Datasuits have never gone mainstream, due to their inherent realtime lag, expense, complexity and incovenience. In the real world, we perceive things and then we move our bodies to pan so we see them straight on. For user comfort, but more for computer speed considerations, selected virtual objects (selvobs) should self-align toward 2space window center, regardless of the interface modality, to realign selvobs with the resting axis of the eye. Since the 2space window representation of virtual 3space (v3space) realigns at its own rate, user disonance derived from perceived lag with head position detection technology does not exist. The lag perception for panning off-screen would be similar to the perception of the delay in moving the physical body to align with a viewed real object, and this is a perception that has already been incorporated into our daily experience. This automates user panning in 3space, since the user's virtual body representation (veebod) follows the eyes.
Similarly, zooming the veebod can be automated by moving toward a selvob at a log rate determined by the vdistance from it and the eye activity with which the user looks at it. The veebod would not be drawn to non-editable virtual objects (vobs); they would exist largely for frame reference. If the eye is fairly still, it is apparent the user wants to take a closer look, in which case the veebod moves in for more detail. But if the user's eye is sweeping out fairly large segments of vspace, the computer can be fairly certain the user doesn't want to move in closer, and may even want to zoom out for an overview.
Datagloveless selvob rotation is an interesting problem I think can be resolved simply by seeing a selvob off-center. This would rotate vspace (and your veebod) around the selvob so your gaze always rests on its center. The concept is really simple: whatever you are looking at comes front and center so you can see it most clearly. If the selvob were another user's avatar, that person would see your avatar moving around them on an arc. If that person were interested in seeing the side or back of your avatar, the two avatars would be in mutual orbit, with the vworld spinning around.
In modelling 3D assemblies, or in looking at files in folders, it is often useful to explode objects to see a vob's innards. Here, blinks are useful as mouse-clicks. It is a fairly trivial to train the user to blink while viewing inactive screen real estate if no action is desired, but in vspace if a selvob is double-blinked, it could ungroup. Later, when its part coordinates fall out of the 2space window (the user is otherwise entertained), its disembodiment attribs could be cleared, and it would re-form as an assembly.
Obviously, we don't have the GET headsets yet. But I don't think it takes a lot of imagination to see we can already start working on a self-centering cursor by integrating it with existing mouse manipulation. I saw a movie a long time ago featuring a text processor running fast on an Apple ][ -- the text insertion point locked to the middle of the screen and the entire text page moved around that point!
To summarize, we have moved thru vspace toward objects of interest, rotated and disassembled them, all without hand motion. I challenge you to see how much richer our explorations of v3space can be with the datagloves tied behind the backs of our veebods!