-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Amstutz wrote: > On Tue, 13 Dec 2005, Neil Mosafi wrote: > >>>> We will also need a way of specifying the destination of the event (a >>>> "shoot" action would probably go to our avatar, but a "press button" >>>> action would go to whatever is in front of us. For mouse events, we >>>> want >>>> to specify what is underneath the mouse pointer, and so forth. >>> >>> >>> Would actions have a source as well as a destination? If so surely the >>> source of the "press button" action should be the user's avatar... how >>> could >>> a browser press a button?
Well in the past you used to be able to have two TerAngreals sharing the same avatar, sort of. This was before you could have your avatar hosted on the server. The first TerAngreal contained your avatar object, and the second used that avatar remotely (moved it). This is so you could have multiple displays on different hosts, for "remote control" at a distant location, for a CAVE like setup, or (what we used it for), simply to observe the behavior of a user who was using a head mounted display. I once made an application, also, that was a big hack, but could have used something like this very action mechanism to work much better. You ran two applications, TerAngreal, and an application-specific GUI application which would create a set of buttons with application-specific commands on them for certain objects it discovered in the world. TerAngreal (this was a previous version, it's now lost all of these features) had an object linked to your avatar which included "browser" information: you could select one or more objects in the world, and those would form a list. You also had a "pointer" which you could place anywhere in the 3d world. The position of this pointer object was included here, or you could clear the pointer and the object would go away. (In theory you could have more than one pointer, say you had a tracking device for each hand, or a table full of them.) Then, these were all objects attached to your avatar, since then remote agents could associate an identity with the browser objects (pointer, selected objects, etc.) and it was a natural way to discover the browser objects. We could easily group them in a "browser" Vobject, and make that a child of your avatar. To get around firewalls you'd unfortunately have to use a proxy object for the browser vobject; it would be ideal if that was local to TerAngreal since updating it would be immediate and would'nt have to go over the network each time. In my hacky application, you could also use the chat channel to give commands but we wanted a GUI with buttons too. The whole thing was kind of cumbersome, since you had (a) TerAngreal, (b) Buttons App, (c) World server, (d) and 2*n or 3*n agents modifying the world (where n scaled from 1 to about 5 I think). And they all had to be started up in the right order. The real problem, though, is that the Buttons App was not really connected to TerAngreal in any way, so it had to infer the association between TerAngreal and your button command based on hostname, basically, which is a bad idea. It would have been better if the Vobjects just had a parent-child relationship. Today, we have omnivos with plugins, which would combine (c) and (d) into one application, and if we implement actions, that combines (a) and (b). This experience is also one reason why I keep suggesting having actions optionally attached to any object in the world, then my (n) special objects could just have menus attached to them. In my application, you selected an object, and your avatar had an object indicating which object you had selected. Reed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDnrmoFK83gN8ItOQRArrHAJ4mpLy8z3vVNhyMhzpCmiHBAqmyzwCdFepm mb98A8EGwWXmNZ6W9bl+NAA= =azHc -----END PGP SIGNATURE----- _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
