From A.Steed@cs.ucl.ac.uk Fri Oct 2 09:56:32 1998 Received: from burdell.cc.gatech.edu (root@burdell.cc.gatech.edu [130.207.3.207]) by lennon.cc.gatech.edu (8.9.1/8.9.1) with ESMTP id JAA24641 for ; Fri, 2 Oct 1998 09:56:28 -0400 (EDT) Received: from wheaten.hitl.washington.edu (IDENT:wx4TIinzay+BA9P+9oLS+Fnuyf6cbPDS@[128.95.73.60]) by burdell.cc.gatech.edu (8.9.1/8.9.1) with ESMTP id JAA21833 for ; Fri, 2 Oct 1998 09:57:24 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by wheaten.hitl.washington.edu (8.8.8/8.6.12) with SMTP id GAA16982 for <3d-ui@hitl.washington.edu>; Fri, 2 Oct 1998 06:57:01 PDT Received: from romulus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 2 Oct 1998 14:56:57 +0100 To: 3d-ui@hitl.washington.edu Subject: Re: Data Flow in a Generic VR Application In-reply-to: Your message of "Thu, 01 Oct 1998 20:05:26 +0200." <19981001180527.1792.qmail@omega.ru.ac.za> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Fri, 02 Oct 1998 14:56:56 +0100 Message-ID: <1847.907336616@cs.ucl.ac.uk> From: Anthony STEED Status: RO I've just joined this list, and the first message is about something right up my street, which is a good sign for a mailing list ... > Firstly, sorry if my posting provious was ambiguous. By interface I meant, > not neccessarily even something as concrete as an API, but rather a set of > recomendations for how data should flow in VR application - a sort of > ISO/OSI Network model , only for VR :) I am currently constructing an architecture > based on those recommendations, in order to test whether (and to what degree) > they are valid. Basically I am try to build a library for rapid prototying > of VR apps. Let me introduce something I wrote as part of my PhD called VEDA (Virtual ENvironment Dialogue Architecture). This was a literal implementation of a data-flow programming paradigm for programming VEs, starting from sensor reading, to body mapping, to surface (collision) event and object behaviours. It implemented a "classic" data-flow language with source, sinks and filters, along the same lines as VRML97 (though it was totally data-driven, whereas VRML97 has some concept of demand based flow). Filters can do mappings on tracker position, logical mappings on booleans, gesture recognition (Virtual Treadmill and others), constraints, animation behaviours etc... I did not make an explicit distinction between interface levels (device/surface/logical), if it was a stream of the right type you could just connect things together. So (for example) "World Save" was triggered either by pressing a virtual button (object-object collision), pressing all the buttons on the 3D mouse simulateously (AND of 3 button device streams), or making a gesture. Our group has always tried to do the most amount of work possible from within the virtual environment, so I programmed a visual programming front-end to the data-flow engine. This meant that you could create (and destroy) user interface metaphors whilst immersed inside the system. For example you could change a fly in the direction of gaze navigation metaphor into fly in the direction of aim (eye->hand relative) by copying, instancing and wiring a few nodes from your toolbox without leaving the application. There is still a huge amount of work to do on construction metaphors, graph representation and so on, but systems move on and that software is now waiting to be re-incarnated on some new hardware (it was implemented in dVS 0.9 on a Division Provision 200 that no longer functions). You should take a look at a system called Carmel from Virtuality who implemented an immersive VR system using explicit representation of interaction in VRML97 (see Chris Hand's paper at VRML97 conference). Carmel also had a 2D visual programming front-end. Of course VPL's Body Electric did a similar 2D thing years ago. I should introduce myself some more since this is my first posting. I work with Mel Slater at University College London. We are interested in group collaboration in virtual environments and one aspect of this is how to support collaborative interaction. We have also worked for several years on the sense of presence and my take on that is how interaction metaphor affects presence. We try to design interaction metaphors to be "body-centered", i.e. involve the whole of the participant's body in interaction. The classic examples of this are the virtual treadmill (miming walking in place to activate navigation), or self-body squashing to activate scaling. Anthony ----------------------------------------------------------- Dr Anthony Steed A.Steed@cs.ucl.ac.uk