From g97rc001@omega.ru.ac.za Thu Oct 1 14:05:26 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 OAA15310 for ; Thu, 1 Oct 1998 14:05:24 -0400 (EDT) Received: from wheaten.hitl.washington.edu (IDENT:paLs4Ajb3+V13axV9Q5LnHXwI/vyCM3f@[128.95.73.60]) by burdell.cc.gatech.edu (8.9.1/8.9.1) with ESMTP id OAA20541 for ; Thu, 1 Oct 1998 14:06:10 -0400 (EDT) Received: from omega.ru.ac.za (omega.ru.ac.za [146.231.24.56]) by wheaten.hitl.washington.edu (8.8.8/8.6.12) with SMTP id LAA03640 for <3d-ui@hitl.washington.edu>; Thu, 1 Oct 1998 11:04:58 PDT Received: (qmail 1793 invoked by uid 590); 1 Oct 1998 18:05:27 -0000 Message-ID: <19981001180527.1792.qmail@omega.ru.ac.za> Subject: Re: Data Flow in a Generic VR Application To: 3d-ui@hitl.washington.edu Date: Thu, 1 Oct 1998 20:05:26 +0200 (GMT) From: Mike Rorke X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi .. > OK, I was confused for a minute there. I assume by "interface" you > mean the API and not the user interface. So am I correct in saying > that you're trying to build a software architechture for VE applications > that will make rapid prototyping and implementing of specific applications > possible? 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. > > Interaction Component(s) : these are the users 'handles' into the world e.g. > > a virtual hand. These relay the users commands (through a standard > > interface) to the system which implemets them, and give the user information > > about the virtual world. > > So this is the user interface, different routines and objects that > the user uses to control the system. Do you think it's possible to > define a standard set of commands that will cover the range of > actions one might want to take? What are some of the fundamental > ones that will definitely be in there? Yes. I think that it will be possible to define a set of actions which will cover the majority of VR apps. There is no limit to how many actions can be in the set, and the idea is to make the data interface between the 'interface' that the user uses and the 'system' as generic as possible, so that any new action can be easily implemented and integrated. As far as what these actions are, I currently have a list of 5 that I have implemented, namely: grab, drop, point, un-point,and press. I am by no means trying to pass these off as a complete list of all actions that should be allowed! One of the things that I was hoping to get feedback on was what exactly people do in their particular VR applications, and what 'actions' would be required to support this. > I think this is an interesting but challenging project. What do > you expect to be able to do when the architecture is in place? > Is it something like the Mac Toolbox for VEs, where everyone uses > the standard interface components and API, so programs look and > feel the same? I'm not trying to set a standard API. I feel that a much better idea is to simply create different API's in such a way that they are able to interact with one another. My ideal here would be for a group of people all to develop API's for a specific field of VR and to be able to integrate all of these into any given VR application. In order to do this, we need to know what information to expect from where. > I have a little experience in something related to this. I took > a taxonomy for VE selection and manipulation techniques and "implemented" > it. Meaning that I wrote separable routines for each of the parts > of an interaction technique, and then code that let me tie any > of the components together to create a full selection/manipulation > technique. It works pretty well, and I have the potential to create > almost 700 different interaction techniques with just the press > of a few buttons. However, it was difficult to do, and there are > still a lot of problems. There are global variables running all > over the place, multi-level dependencies between routines, many > combinations that probably wouldn't work, etc. I'm wondering if > trying to do something like this for a complete VE application > is feasible. This sounds like what I am eventually aiming at. I am trying to avoid global variables, etc. by designing this framework first. This will (hopefully) give me a clear set of boundaries/information interfaces. These can then be used to implement all the different components in such a way that the implementation specifics of each are transparent to the rest of the system. I think it can be done - though not easily. Possibly I am going to have to limit myself to some specific field of VR application at some point, but, at the moment I would like to keep it as general as possible. > I'm especially interested in how you view this from the programmer/ > designer's point-of-view. The way I read your message, they will > be writing their own interaction techniques that will interface > with your architecture. How rigid and limiting will the architecture > be on what these routines can do? How hard will it be to write a > routine for an existing technique within your framework? How it works at the moment is that I have a parent object with a set group of virtual methods. On its own, the parent object does little/nothing. The idea is that you build child objects which inherit from the parent and overload/implement the procedures required. The rest of the system communicates with the parent object using the specified methods, which are actually carried out by the overloading child process. This does give a fairly rigid framework from the point of view that you have a set number of 'things' that your component is allowed to do. The way I hope to minimise this problem is to investigate what it is that each component needs to do, and tailor the allowed methods appropriately. Of course it is easy enough to add more methods into the origional parent object, provided that you adhere to the information interface with the next level up in the inheritence. > Thanks for the message - hopefully we will start some fresh > discussion here... Thanks for your feedback. I have only recently begun work in this field and accept any comments, suggestions, etc. very gladly. Mike ------------------------------------------------------------- "I took the money, I started to drink You miss too much these days if you stop to think" -U2 Michael Rorke mrorke@cs.ru.ac.za Computer Science Masters mike@rucus.ru.ac.za Rhodes University, Grahamstown http://rucus.ru.ac.za/~mike ------------------------------------------------------------- * Standard ANSI disclaimer *