VRML Behaviors Workshop
Mitra 31 Oct 95
This document is part of a collection of VRML2.0 history at http://www.mitra.biz/vrml/vrml2/mw_history.html
Please let me know any mistakes, especially if I've misrepresented someone's position on any of the issues.
The behaviors workshop at SDSC in San Diego drew around 40 participants interested in adding behaviors to VRML. A significant fraction were also interested in adding multi-user capabilities to VRML although there was no time to address this as well.
Most of the first day was taken up with presentations of behavior within existing VRML systems. This showed both the potential for this, and the need for standardisation work to ensure that worlds would work across different browsers.
The debate basically came down to the difference between Gavin's dataflow model and SDSC, SONY and my event handler model. After some additions to the dataflow model it was clear that either model could do any task, it was mostly a question of how easily. After much debate there was an informal poll of developers, with SDSC, SONY, DIVE, Chaco, Superscape, Lockheed, Worlds and EnterTV favoring the Event driven model, and BSI and DimensionX undecided.
The event then split into three sub-groups, with about 20 people going over the nitty gritty details of the event model. We were basically working from the behaviors and api proposals at http://www.mitra.biz/vrml/vrml2/vrml-behaviors.html and http://www.mitra.biz/vrml/vrml2/vrml-api.html, and looking for the open issues, areas for further work etc. The following points were discussed, and some conclusions drawn.
- Firstly, there was strong consensus on most of the model, with agreement that almost all of the details are minor, and that the basic framework is right.
- The model of the EventHandler is good, but its an open issue as to whether this should exist as a specific VRML node, or be added dynamically by the behavior. The advantage of having the node is that in some cases it gives better composability, and also allows trivial behaviors to be written directly in the VRML, the disadvantage is that it gives two ways to do the same thing. I believe the consensus was to experiment with implementation and see just how usefull it is.
- It should be noted that SDSC thinks of events and messages seperately, the notes below do not neccessarily reflect this distinction.
- Whether or not we have an EventHandler node, its fields are worth discussing, since they will be the same for dynamically add nodes as for statically written ones.
- The list of events needs extending to include CULL_IN, CULL_OUT and MOVE
- Sony suggested an "output" field, that could be used as a hint to the browser as to what would be modified, there was some resistance since it was felt that most browser developers would ignore it.
- There is an open issue as to where the mapping between the event (e.g. Pick) and the interpretation (e.g. Turn On) needs to happen. This can basically happen in one of three places
- in the EventHandler, for example eventType=PICK, actionMethod=TurnOn - this is preferred by Sony, and Mitra
- In the interpreter, the "AddEventInterest" call is caught by the interpreter, which keeps a data structure of events and mappings. This is preferred by SDSC. (Note this is incompatable with EventHandlers written into the VRML since the interpreter has to catch the AddEventInterest call).
- In the Applet, the applet received "picked" and turns it into "turnon" - this is preferred by Java.
Methods 1 and 3 are compatable, i.e. if actionMethod is specified then send the message, otherwise just send the event.
- The API calls from the browser are basically sound, but some details need addressing.
- Probably Events and definately Messages need to indicate where the event/message was sent from, to enable the receiving behavior to add security.
- Events and Messages need to say where the event happened as well as where it met the event handler, for example a Pick on a finger might be caught by and event handler on the Arm. The event-script (associated with the arm) needs to be able to know that the event happened on the finger.
- The cascading behavior of EventHandlers needs specifying in the paper. There is a tough issue of cascading and multiple events, i.e. how to control when an event is propogated up the hierarchy and when not. The issue breaks down to whether a event-script can control cascading, and how to do this before waiting for a possibly asynchronous event to be handled. It is likely that there will be a need for a field on the EventHandler to control cascading.
- This does not address the issue of what a communications protocol looks like for doing this in a multi-user environment. As long as the comms is handled in an Applet, or plug-in, then this doesn't have to be decided now, and modules that support both DIS and Server-based schemes can be built.
- The prototype node needs extending to support local variables, scoped by the PROTO, or some other way for items inside a prototype to access each other without exposing themselves outside the prototype.
- It would be usefull to add a Global event Node, to catch events, this would be checked before the tree was checked in order to allow modal behaviors - e.g. click on an object, the next Pick specifies the destination. A global behavior wants to catch the pick event, and know what was picked.
- There are a number of open Name Resolution issues, especially as to what can be accessed - the choice seems to be between
- Interfaces on this Prototype/behavior
- 1 + Interfaces on Pseudo Nodes (e.g. orientation of camera)
- 2 + Interfaces on any named node
- Any field of any named node
Most people seem split between either 1 or 3.
- Open issue - how to pass userData across the interface, choice seems to be between a rich paramater interface, i.e. specify any number of paramaters - and field references - in an Event Handler, or a simpler interface where only a string is passed, and the event-script uses call-backs to get values etc that it needs.
- There is an open issue of how to do referencing and object counts. I think it was agreed that cookies should be passable across the interface, i.e. using the ResolveField, SetField, FreeCookie style of calling, but I might have missed an argument against this.
- Do we want the script to be able to read arbritrary geometry, and if so how?
- The issues of control and authorisation will have to be addressed at some time - but probably not now?
- The specific interface for different platforms needs addressing - specifically Mac, Windows, Unix shared libraries, and Sockets (SDSC's scheme for interpreters on different machines from the browser)
- An updated paper reflecting these points should be out for comments soon.