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. |
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. |
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 |
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!" > > > > |
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. |
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. |
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? |
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 |
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 |
Free forum by Nabble | Edit this page |