Re: Navigation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Navigation

nick hemsley
This would be cool to see (i.e. 3d gesture recognition via multiple webcams), but it doesnt seem to be viable yet (lack of code out there, lack of computer power). writing an input/event system that worked with gestures would be interesting to say the least.

On 3/3/06, David Faught <[hidden email]> wrote:
Then of course there is the whole area of physical interaction.  An gestural method of manipulating objects using a simple commodity webcam as input could be fun.

What webcam image would you rather see appear in a 3D space, a flat (or even surface-mapped) image of a talking head, or someone waving their arms wildly, trying to swim to the portal first?


Reply | Threaded
Open this post in threaded view
|

Re: Navigation

Hans N Beck
Hi,

For me navigation  has these aspects:

1) identifing the position of the goal (not the goal itself!)
2) identifing a way to the goal from current position
3) identifing the own position every time

So in all cases, we have to deal with positions. And how are they  
defined exactly ? A mathematican would use a free defined but then  
fixed coordinate system. A child would say "next to the place where I  
go to school" or "first I go around this and along there and there it  
is". Cats would reference it's accoustic picture in mind. For  
convinience I would call these methods

a) geometrical (y=f(x,y,z...))
b) topological (next to...)
c) behavoural (move here, then go right....)
d) pattern matching  (the cats acoustic picture)

navigation methods.

 From this I would ask, which information we need to navigate in a  
space like croquet ? Geometrical ? Topological ? Well, I think it is  
obvous that this would depend what the user will do. For simulation  
or mathematical based applications the use of the concept of  
euclidian space may be right. But now assume a artificial (in the  
sense of not naturally for our sensoric expirience) information space  
like Requirements for a software system . Which reference would be  
good ?

Conclusion: Croquet should have not *that* navigation tool or method,  
but should provide navigation methods by allowing to define  
difference reference systems, both absolute and relative.

Now the next point would be the amount of information needed for  
navigation. In these days of computer, we are living with a huge  
amount of information at one time *and* one place. And with the goal  
of some programmers to show really all in one screen :-) There may be  
applications to see the hole picture, all members of the information  
set. But I think the normal way for humans is not to work with all at  
once. Even if we interested in visualizations of overall structures,  
we are not interested in details. Using a street map for far travel  
we will need the information witch higway to use, not all small paths  
or streets along that way. These would be only interesting  
informations at start and end. The set of elements used for defining  
a position I  would call navigation space.

Conclusion: Croquet should have the ability to filter over the  
members of the navigation space. It should be able to let the user  
show that members he wants to see. Or better:  which are needed to  
perform the navigation task usefully. And in addition, the members  
should be classified by this navigation task (in the case of the  
street map: highways, railroad tracks, hotels....).

For the last, the question is how to display the navigation space. In  
the case of street maps this may be obvious, Other possibilities for  
Croquet may be showing graphs or subspaces linked by portals, as  
mentioned here in this list. In addition, I would suggest something  
similar which is common in the database world: the space itself,  
where you are moving, is created especially for this current  
navigation task. Often, by using geometrically based information or  
even in some sf-movies, the space (what ever it's elements are) is  
fix, and there is some guide like a oversight view or wizard to find  
something in this space. But what, if the space itself changes  
according to the navigation  task ? This would be interesting for  
method b) to d), I think.

Conclusion: Croquet should provide some features to combine directly  
filtering, annotation and space creation for both, programmers and  
users.

So, there is nothing new here, and I know that there are efforts from  
Croqueteers for filters, annotations etc, but I have no access to  
details. This is only some *very rough* outline from questions which  
I asking me for navigation in Croquet and to which I'm interested to  
know what   the current state of the discussion of the croqueteers is.

Regards

Hans

Am 02.03.2006 um 14:15 schrieb David Faught:

> I have also dreamed up an information storage scheme where each  
> nugget of knowledge would be presented in a portal window (one way  
> or another), and zillions of portal windows would be arranged  
> around a central point in concentric spheres, with adequate space  
> between the spheres for convenient viewing and some specialized  
> controls for "zooming" between spherical levels.  Some kind of  
> position indication clues would also be good, such as a heads-up  
> display of heading and distance vector from origin.
>
> I have no clue how useful this would really be, but it seems to be  
> an efficient packing method of placing lots of information in a 3D  
> space, while allowing fairly intuitive visual navigation.
>
> In fact, it seems to me that this kind of circular (in a ground-
> parallel plane) or spherical layout is a natural for easy viewing  
> and selection of a group of portals, such as the Architect portals  
> in the standard Jasmine Teapot demo space.


Reply | Threaded
Open this post in threaded view
|

Re: Navigation

Howard Stearns
In reply to this post by nick hemsley
On Mar 7, 2006, at 7:10 AM, David Faught wrote:

> Talking about the avatar as a special case of the objects that  
> might use navigation services, I remember Julian Lombardi saying  
> that his team had integrated the "WASD" keys type of movement, in a  
> similar manner to what many PC games use.  In this way, these  
> keyboard keys are used to move around while the mouse is used to  
> point at and select objects.
>
> One of the disconnects in this for me is the difference between  
> looking and pointing.  Many PC games just couple looking and  
> pointing together, so that you are always looking directly at what  
> you can select.  On the other hand, Croquet Jasmine normally just  
> points, and a special key combination must be used in order to look.
>
> Visualizing a person reaching for an object, their arm can move  
> directly to the object without moving the rest of their body, as  
> long as the object is within the sphere of movement of their arm.  
> If the object is only a little further, they will lean or twist the  
> rest of their body to be able to reach the object.
>
> Something similar to this could be done in Croquet to "loosely  
> couple" pointing and looking.  For example, establishing a  
> rectangular area between 1/2 to 7/8 of the area of the Croquet  
> camera view, centered in that view, could allow for "pointing only"  
> as long as the mouse cursor is within that rectangle.  If the mouse  
> moves towards the edge of the camera view, the avatar could turn to  
> look in that direction thereby extending the range of what can be  
> pointed at.  This type of edge-scrolling is used in many games and  
> other GUIs, and could make avatar navigation much easier in Croquet.

At the same time as the keyboard-driven avatar-movement, we also  
implemented "mouse look:"  moving the mouse in the center of the  
screen did it's usual Croquet thing, but moving within a vertical  
band at the the left and right edges turned you to the left or  
right.  (There were actually two vertical bands next to each other at  
each edge. The inner pair rotated slowly, the outer pair rotated fast.)

Everyone hated it.

But we never had time to study why. It might be as simple as the fact  
that we didn't have a visual indication of where the vertical bands  
were. E.g. a translucent grey overlay to identify the mouse-look region.


Howard Stearns
Croquet Lead Developer, http://croquetproject.org
DoIT Academic Technology, http://www.wisc.edu/academictech
University of Wisconsin-Madison, 1301 University Avenue, Madison, WI  
53715
  +1-608-262-3724


Reply | Threaded
Open this post in threaded view
|

Re: Navigation

David A. Smith-3
In reply to this post by nick hemsley
It is an interesting balance that must be kept. First, I assumed that
Croquet would be used for entering text perhaps as much as moving around
in a space. This meant that the keyboard had to be left pretty much
alone - we could not just appropriate the wasd keys, as you might want
to use those to type a letter someday. I don't like modes, so I tried to
avoid them as much as possible. Modes in Croquet are currently the soft
modes due to mouse down events.

I thought some of the 2D/3D stuff that I saw in Doom 3 was quite nice,
in that, though the cursor was always in the center of the screen - it
wasn't too hard to select buttons and things on their virtual computers
in the game. The problem was still text input wasn't used (and wasn't
really necessary in their context) so there was no way to judge how this
would work.

One thing to try is to use a mouse-look interface, but have the right
button used for moving forward in the direction you are looking. A
variation on this would be to move forward if you are looking slightly
up and backward if you are looking slightly down - using the cross-hair
as a guide. Left and right strafing can be done using the left and right
arrows, which means these keys are a bit overloaded in functionality,
but they are already anyway.

The current design (Hedgehog) sends all unused keyboard messages to the
avatar now. This just means that if you happen to be looking at a
keyboard accepter, you may limit your movement ability.

Also, note that the pointer in Croquet was intended to be uncoupled from
the screen. That is, it should allow a user in a cave to hold a wand as
an input device. Currently, we don't support that, but that was the
intent and we really need to make sure the system supports that kind of
interface.

Regards,

David


David Faught wrote:

> Howard Stearns wrote:
>  
>> At the same time as the keyboard-driven avatar-movement, we also
>> implemented "mouse look:" moving the mouse in the center of the
>> screen did it's usual Croquet thing, but moving within a vertical
>> band at the the left and right edges turned you to the left or
>> right. (There were actually two vertical bands next to each other
>> at each edge. The inner pair rotated slowly, the outer pair
>> rotated fast.)
>>
>> Everyone hated it.
>>
>> But we never had time to study why. It might be as simple as the
>> fact that we didn't have a visual indication of where the
>> vertical bands were. E.g. a translucent grey overlay to identify
>> the mouse-look region.
>>    
>
> I could see this being a "human factors" kind of issue.  There are several variables that could probably be tweaked to improve the "feel" of this, such as the translucent overlay you describe, the overall width of each area, a graduated maybe cosine-interpolated turning speed, just the turning speeds chosen themselves, etc.  I still like this idea because it simplifies the overall interface for the user and allows a wider range of motion.
>
> Who was "everyone?"  Maybe it's an inertia issue, "I've always done it this way!"
>
>
>
>  


Reply | Threaded
Open this post in threaded view
|

Re: Navigation

Mark P. McCahill
In reply to this post by nick hemsley

On Mar 7, 2006, at 8:48 AM, Howard Stearns wrote:

> On Mar 7, 2006, at 7:10 AM, David Faught wrote:
>
> At the same time as the keyboard-driven avatar-movement, we also  
> implemented "mouse look:"  moving the mouse in the center of the  
> screen did it's usual Croquet thing, but moving within a vertical  
> band at the the left and right edges turned you to the left or  
> right.  (There were actually two vertical bands next to each other  
> at each edge. The inner pair rotated slowly, the outer pair rotated  
> fast.)
>
> Everyone hated it.
>
> But we never had time to study why.

I know why I hated it. Having menus and dialog boxes along with  
mouselook lead to a very irritating user interface. Even with  
mouselook confined to the sides of the screen, a menu or a dialog box  
or a text entry area (like for in-world annotations) would tempt you  
into moving your mouse over to the edges of the screen sometimes, and  
then your viewpoint changed because you were in mouselook territory.  
Mouselook needs to be something other than the default mode and  
something you do when you are not using menus or doing any text  
entry... but this leads us into modes-ville.

> It might be as simple as the fact that we didn't have a visual  
> indication of where the vertical bands were. E.g. a translucent  
> grey overlay to identify the mouse-look region.
>

Even with visual indications, the temptation of selecting something  
in a text entry area, or choosing an item on a menu that happens to  
be at the edge of the screen is a problem.

Reply | Threaded
Open this post in threaded view
|

Re: Navigation

David Faught
In reply to this post by nick hemsley
On 3/7/06, Mark P. McCahill <[hidden email]> wrote:

>
> On Mar 7, 2006, at 8:48 AM, Howard Stearns wrote:
> >
> > At the same time as the keyboard-driven avatar-movement, we also
> > implemented "mouse look:"  moving the mouse in the center of the
> > screen did it's usual Croquet thing, but moving within a vertical
> > band at the the left and right edges turned you to the left or
> > right.  (There were actually two vertical bands next to each other
> > at each edge. The inner pair rotated slowly, the outer pair rotated
> > fast.)
> >
> > Everyone hated it.
> >
> > But we never had time to study why.
>
> I know why I hated it. Having menus and dialog boxes along with
> mouselook lead to a very irritating user interface. Even with
> mouselook confined to the sides of the screen, a menu or a dialog box
> or a text entry area (like for in-world annotations) would tempt you
> into moving your mouse over to the edges of the screen sometimes, and
> then your viewpoint changed because you were in mouselook territory.
> Mouselook needs to be something other than the default mode and
> something you do when you are not using menus or doing any text
> entry... but this leads us into modes-ville.

It seems to me that just having menus and text entry boxes show up on
the screen implies that there are modes.  I am not in love with the
top-of-the-screen Windows-style menus that Tweak has anyway, I much
prefer the context-style menus that Squeak (Morphic?) uses.  Context
menus can be positioned in the middle of the screen, being modal while
there, and could just disappear if the cursor moves away without
selecting.

I guess that where I am really headed with this is that optional
preferences for enabling and disabling some of this stuff would go a
long way towards tailoring the interface for various tasks and users.

Reply | Threaded
Open this post in threaded view
|

Re: Navigation

David Faught
In reply to this post by nick hemsley
On 3/7/06, David A. Smith <[hidden email]> wrote:
> It is an interesting balance that must be kept. First, I assumed that
> Croquet would be used for entering text perhaps as much as moving around
> in a space. This meant that the keyboard had to be left pretty much
> alone - we could not just appropriate the wasd keys, as you might want
> to use those to type a letter someday. I don't like modes, so I tried to
> avoid them as much as possible. Modes in Croquet are currently the soft
> modes due to mouse down events.

Yes, an interesting balance indeed!

> The current design (Hedgehog) sends all unused keyboard messages to the
> avatar now. This just means that if you happen to be looking at a
> keyboard accepter, you may limit your movement ability.

So this is a matter of focus indicated by the mouse cursor, and if the
object with focus doesn't want the message, or there is not object
with focus, then the avatar gets the message?

> Also, note that the pointer in Croquet was intended to be uncoupled from
> the screen. That is, it should allow a user in a cave to hold a wand as
> an input device. Currently, we don't support that, but that was the
> intent and we really need to make sure the system supports that kind of
> interface.

Are you actually talking about a physical wand in a person's hand as a
PC input device, or a virtual wand in the avatar's hand, or both?  If
this is a virtual wand, then it would just be a different appearance
of the current "laser pointer", wouldn't it?  How would it function
differently, other than the magic aspect of course?

Reply | Threaded
Open this post in threaded view
|

Re: Navigation

Hans N Beck
In reply to this post by nick hemsley
Hi,

Am 09.03.2006 um 20:09 schrieb David Faught:

> Chris Muller wrote:
>> I hope you guys don't mind my commenting about this..
>
> As long as there is an honest interest, I think it's "the more the  
> merrier."  Nobody minds, although many of the list members are  
> probably getting tired of hearing from me ...

not as far as it belongs to me :-)

Regards

Hans

Reply | Threaded
Open this post in threaded view
|

Re: Navigation

Hans N Beck
In reply to this post by nick hemsley
Hi,

Just for interest: is there a certain team working on navigation  
concepts (for moving, searching and orientation), for example at any  
university or some potential member of the comming consortium, or in  
form of a spectial (sub-) project,  or is it more a matter of the  
main croquet development team ?

Regards

Hans