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 NAA19734 for <ddgarcia@coons.cs.Berkeley.EDU>; Tue, 15 Apr 1997 13:16:49 -0700
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 NAA26612 for <ddgarcia@cs.Berkeley.EDU>; Tue, 15 Apr 1997 13:16:44 -0700
Received: (from ftp@localhost) by kohler.CS.Berkeley.EDU (8.8.3/8.6.9) id NAA27402 for ddgarcia@cs; Tue, 15 Apr 1997 13:16:42 -0700 (PDT)
Date: Tue, 15 Apr 1997 13:16:42 -0700 (PDT)
From: CS Anonymous FTP <ftp@kohler.CS.Berkeley.EDU>
Message-Id: <199704152016.NAA27402@kohler.CS.Berkeley.EDU>
To: ddgarcia@cs.Berkeley.EDU
Subject: WWW form from quito.cs.berkeley.edu

PROJECT_STATUS01_NAME1=David Gibson
PROJECT_STATUS02_NAME2=
PROJECT_STATUS03_NAME3=
PROJECT_STATUS04_TITLE=Programmable VRML worlds
PROJECT_STATUS05_DESCR=
The proposal stands pretty much unaltered: although I might cut down a
bit on the breadth issues - making every single vrml node type editable
- in order to concentrate on the more interesting issues of designing a
usable implementation framework, and to give time to experiment with
interaction designs.

I can add another goal to the project: to evaluate the current
generation of VRML2.0 browsers.  This application requires a lot of the
browser, and I've yet to find one which can handle everything.  VRML is
still under development, and I might come up with some suggestions for
improving the browsers, or even the spec.  I do not intend to make this
an exhaustive evaluation, but I will be doing quite a bit for my own
purposes anyway.


PROJECT_STATUS06_WDONE=
Browser shopping
~~~~~~~~~~~~~~~

Tested just about every vrml2 browser there is.  What I really require
is a browser with complete Java support which runs fast under NT or Irix 5.3.
Unfortunately, most PC browsers are optimized only for Windows 95 -
Direct3D for NT is in the works still.  And the Java support varies.

Here is a brief summary of browser capabilities.

GLView - NT:            fast, no java, bad proto support 
Cosmoplayer - Irix5.3:  fast, no java!  irix6 needed.
Cosmoplayer - NT:       slow, java ok, colors messed up
Liquid Reality - NT:    slow, java support great.
WorldView - NT:         ???, java broken.   Graphics need some hacking.

Liquid Reality also runs on suns, so I can use my workstation, if slowly.
I'm having second thoughts about its capabilities now, there have been a
few examples it can't handle.  (nested PROTOs, createVrml, IS eventOuts)
Others:
Live3D - not tested
Torch - new arrival, not tested.
Sony Community Place needs another look too.  Slow, java ok.  Won't load Floops.

So my best option right now is Cosmo.  LR is also almost ok.  But both
are slow.  Intervista's WorldView promised Java, but when I couldn't get
it to work they said they'd found a bug...

Question: What software is installed on the Indigos, and how do I get
access to them?  Cosmo on Irix 6.x would be nice.

---
Learning VRML
~~~~~~~~~~~~

Done.  Some of the sensors and suchlike have quite involved behaviour,
but I'm able to get whatever I need working now.

The PROTO and routing mechanism is a bit more subtle.  The spec does not
make it entirely clear how PROTOs are actually dealt with at run-time,
and in fact it is impossible to extract some details of the scene (such
as routes or prototype internals), once it has been parsed.  Workarounds
have been devised.

---
Requirements for an editable world
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Built out of composable components
VRML friendly - should respect the VRML model and able to edit VRML
Support for complex user interactions
Reflexive: should be able to edit the editing tools too

---
Design
~~~~~

I've come up with a world-manipulation model which mimics the structure
of the VRML scene graph quite closely.  It will allow edited worlds to
be written out in standard vrml format, or in enhanced format for later
editing.  Standard world files have to be modified slightly before they
are read in, because of the hidden details mentioned above.

All world objects (ie, protos) in this model are extended with a few
extra fields to allow editing.  However, they maintain a notion of what
they should look like in a standard, nonenhanced, world.  (In the case
of Transforms, etc, they shouldn't _look_ like anything).  Each node in
the scene graph can display in its normal (nonenhanced) state, or in
Fieldedit mode, where, for example, a Transform node would provide
controls to adjust its scale, manipulate its children, etc.

Additionally, exactly one node can be in Open mode.  In this case, the
internal workings of the prototype are displayed, along with a
switchboard structure representing the proto parameters.  
Initially, it is as if the top-level scene is in open mode (except for
the lack of parameters).  When another node is opened, all objects above
it in the scene graph vanish: this makes editing cleaner.  (Hopefully.
It might become necessary to display the rest too).

In the theory of object-oriented programming, this is working on a
prototype-clone model, rather than a Java/C++ style class-instance
model: there are no uninstantiated classes, and the only method of
creating new instances is by "cloning" (deep-copying) a node.

Programmability would come from the composition of a suitable library of
script nodes, computing suitable functions, composed using the routing
scheme, along standard data-flow programming lines.

This is just a brief sketch - most other details are still in my head.
The tricky bit is coming up with a model which is actually workable in VRML.
But it seems to me like the current design is both feasible and usable.

---
Implementation so far
~~~~~~~~~~~~~~~~~~~~

Not too much yet.
Built several useful prototypes and scripts.
Finding out how not to break the browsers.


PROJECT_STATUS07_INPUT=Mouse
PROJECT_STATUS08_OUTPT=Monitor
PROJECT_STATUS09_SYSTM=VRML
PROJECT_STATUS10_DEADL=
Overall plan:
 Modules to code
  Field editors
*  scale, rotation, position 
   int, float, bool
*  MFNode  
   others: colors, arrays of various sorts.
  Node editors
*  cone box cylinder sphere  
   viewpoint
   sensors
   script
   others: interpolators, materials, anchors
  Useful nodes
   scripts
   other manipulators
  Parameter editor and open mode
* Route editor  
  Vrml converter
* Node cloner
  Vrml writer
 Interaction design and experimentation
 Writeups

Those marked with a (*) are most crucial to demonstrate a coherent
system.  It will allow for an editable world, where objects can be moved
about and altered and copied, but no high-level abstractions can be
made.

This is what I vouchsafe to have implemented by next Tuesday.


PROJECT_STATUS11_URL..=http://www.cs.berkeley.edu/~dag/VR/report.html
PROJECT_STATUS12_QUEST=
 What software is installed on the Indigos, and how do I get
access to them?  Cosmo on Irix 6.x would be nice.

If Cosmo gets support for stereo viewing, I'd like to use the 
Crystal Eyes too.
