Re: Navigation

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.

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:

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. 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

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:

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

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.

On 3/7/06, Mark P. McCahill <[hidden email]> wrote:
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.

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?

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

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