Return-Path: ftp@kohler.CS.Berkeley.EDU
Received: from hofmann.CS.Berkeley.EDU (hofmann.CS.Berkeley.EDU [128.32.35.123]) by coons.CS.Berkeley.EDU (8.8.3/8.8.2) with SMTP id OAA28628 for <ddgarcia@coons.cs.Berkeley.EDU>; Tue, 18 Feb 1997 14:02:30 -0800
Received: from kohler.CS.Berkeley.EDU (kohler.CS.Berkeley.EDU [128.32.35.31]) by hofmann.CS.Berkeley.EDU (8.6.11/8.6.6.Beta11) with ESMTP id OAA01172 for <ddgarcia@cs.Berkeley.EDU>; Tue, 18 Feb 1997 14:02:29 -0800
Received: (from ftp@localhost) by kohler.CS.Berkeley.EDU (8.8.3/8.6.9) id OAA02203 for ddgarcia@cs; Tue, 18 Feb 1997 14:02:27 -0800 (PST)
Date: Tue, 18 Feb 1997 14:02:27 -0800 (PST)
From: CS Anonymous FTP <ftp@kohler.CS.Berkeley.EDU>
Message-Id: <199702182202.OAA02203@kohler.CS.Berkeley.EDU>
To: ddgarcia@cs.Berkeley.EDU
Subject: WWW form from quito.cs.berkeley.edu

VRP01_NAME1=David Gibson
VRP02_NAME2=
VRP03_TITLE=Programmable VRML Objects
VRP04_DESCR=
Objective: 

To create a suite of VRML objects which can be manipulated and
programmed, and used to build further objects, by interacting with them
in the virtual world.

This is useful in a number of ways:

- If it is extended to full generality, it will be a
  platform-independent VRML editor - all that is required is a VRML
  browser!  I envisage some mechanism to export the current state of the
  world, without the manipulation hooks, for others to view.  (True,
  Liquid Reality's editor is already platform independent, due to Java)

- Since the editing process is entirely within the VE, there is no need
  to remove HMDs, gloves, and other apparel.

- It allows a very rapid turnaround time for experimentation with different 
  behaviours.  In particular, I would like to experiment with many
  different viewing models - modes of transport, in a way.


Hardware: 

 Either the Indys in 349 Soda, or Pentiums in 111 Cory.


Methodology:
 
 I've done some preliminary reading to find out whether this project is
 feasible.

 VRML's TouchSensor and other sensor nodes allow complex enough mouse
 interaction - one could have pull-down menus on objects very easily,
 for example.

 Embedded Java code can be granted access to the entire scene graph,
 so it can thus be modified, loaded, and saved easily.  The browser API
 does not provide a direct way to save the current graph, so this will
 have to be written.

 I must yet see whether the Java securities allow invoking external
 programs (such as the Java compiler and the occasional text editor,
 although I want to avoid this as much as possible).

 A large part of this project will be devising (and implementing)
 suitable programming mechanisms, to make the editing process powerful and
 intuitive.

