This document is part of a collection of VRML2.0 history at

Comments on SGI's comparison paper

This document comments on We refer to this paper as the 'SGI comparison paper'.

The latest version of this paper is This paper should be read in conjunction with two others we have written: 'Extension to VRML1.0 [3]' which discusses our extensions to VRML and provides a number of examples of scripts to support behavior. 'An OO perspective on VRML [4]' this paper supports our approach by explaining our underlying philosophy

Kouichi Matsuda, Yasuaki Honda, Rodger Lea
{matsuda, honda, rodger}
Sony Computer Science Laboratories Inc. 
also with Central Research Center, Sony Corporation


Thurs Nov 16 10:41:27 JST 1995: the first version

1. Overview

The SGI proposal has some nice features, Mitra has already picked up on a couple of these and incorporated them into our joint proposal, (refered to in the SGI comparison paper as the MSS proposal). The latest version of the MSS proposal can be found at: 'Latest MSS behavior proposal'[2]'

There are several other papers not directly referenced by this memo but which are worth reading, they are '[1]' '[5]' '[6]' In this short document we try to outline our (Sony) priorities in terms of what we want VRML to be able to do, and contrast this with what we believe the SGI proposal is trying to do.

Goals of our Event Model:

I think it is fair to claim that if we had a clean sheet of paper then we would prefer to restrict VRML to a simple scene description language (as it once was) which would be used by a programming language to display certain graphical objects.

Although this is no longer possible, it is still our belief that we should:

In essence, our view point is that we should re-use as much of our existing computing environment as possible, and not build mechanisms into VRML to replicate the computing environment.

In addition, we at Sony have a slightly different priority list:

It is important to understand this 'world view' to be able to understand both the thrust of our VRML proposal and our concerns with the SGI proposal. In the following text we try to pick up on problems we see with your approach. It should be borne in mind that the problems we highlight stem from our viewpoint; we have no doubt that the SGI proposal will work and work well for their goals, our concerns are that it will not work well in the cases we are most interested in.

Answers to SGI's comments:

*Performance, Optimisation and Semantics*

We agree that performance is very important. However we believe that the SGI approach to script optimisation is based on a browser centric viewpoint. By this we mean that in the SGI model the browser acts as the run-time for the 3D application. This allows them to make statments like "decide not to run the script because its results are irrelevent" (2nd bullet, section "Arbitrary effects on scene" SGI comparison paper).

We believe that the browser is a key component of the application, but that it is the component whose primary responsibility is 3D scene management, nothing else. Thus you cannot skip execution of scripts unless you (or the browser) really knows about the semantics of the scripts in question. Scripts are potentially the source of effects from the VRML world to the real world. A script may perform some I/O operation (for example) to communicate with the real world. Such script execution cannot be skipped for optimization purposes if it has side effects like I/O. The side effect includes any variable value update. In other words, we don't believe that your optimization scheme can be applied widely unless you have further hints from programmers.

There are several cases where we feel that your optimisation scheme may not work well. For example, one of the important optimisations that you want to do is to skip script execution for animation when it is invisible (eg the animation is performed behind you). However, it can be possible that a part or the entire animation would become visible during or after the execution if the script was actually executed. If you skip the execution of animation because it was invisible only at the start time, then it changes the semantics of the world and hence this cannot be regarded as optimisation any more.

Another case is the history sensitive input example. If the latest mouse position is always the only concern, then optimising out the script execution which depends on the previous mouse position is possible. However, if a script depends on a history sensitive input value (perhaps the input value is relative to the previous input value), then optimising out the script execution will not work very well. Again we have strong reservations about your claim that "In most cases a script does not care about the history of changes to things it depends on" (2nd para, excessive script invocation section). This may be true for trivial scene manipulations, we don't believe it is true for scripts that work as part of large scale applications such as shared interactive worlds.

Excessive script invocation

We mostly agree with the arguments you made in 'Excessive script invocation' under the assumption that variable value change is the primary source of triggers for script execution. In your example you translate most of the events in our model into some variable value changes. We have some reservations about the use of the FieldEvents and would like to revisit this part of the MSS proposal.

Our main concern is that we think that watching variable value changes tends to cost a lot, hence should not be used as the trigger of script execution. The whole essence of an event driven model is that events are posted when they happen, they are self selecting, there is no need to check all possible events to see if any have happened.

In the same section, you say that simultaneous multiple inputs will cause (by default) the script to execute once You claim that this approach will help alleviate a percieved performance problem. However, in reality, all the object-oriented programming languages (including C++, Java, CLOS and the Smalltalk-80 related languages) do not employ such semantics and still they perform very well. Our model is quite similar to them: events are thought of as messages and scripts as methods in these languages.

We are also concerned that the logic node proposal will lead to implementation specific behaviour. For example, you discuss the case where a script depends on multiple inputs and imply that in your proposal a script will only be executed once when the inputs are set. In the TimerEvent section you discuss your notion of time and imply that the discrete sampling rate is implementation dependent. In a system that relies simply on scripts as the source of events (in your terms output values) such behaviour will be acceptable, because of the synchronous nature of your execution model. However, if we combine these two features in the presense of asynchronous external events, we arrive at a situation where it is quite possibly that in browser A the time interval allows only one value to change, whereas in browser B two values change. Thus in browser A the script is executed twice whereas in browser B it is only executed once.


Reusability should address two issues: reusability of VRML files and reusability of scripts. The SGI proposal addresses the latter. However our approach addresses primarily the former. We think that minimising script related things in VRML files will make them more reusable. In this sense our VRML file is more reusable than the one including logic nodes.

With respect script re-use, harking back to our original point about using the existing computer environment. Most languages have some mechanism to support re-use. We want to use that mechanism, not re-invent our own for VRML. We accept that scripts that are bound to fields are not necessarily reusable, however existing code fragments in most programming languages that directly access fields are not necessarily reusable either. Never-the-less, languages provide other mechanisms to support re-use.

Access control:anonymous nodes

Access control through anonymous nodes seems to be a feature that has fallen out of your model. We are suprised that you would be happy which such a limited and simplistic approach to security. We feel that security is an important issue, and should be addressed, but we think it is an issue that requires considerable work and should not be based on ad-hoc features of an existing proposal.


Persistence is a good point and an issue we haven't considered in any depth. However, again we feel your approach will not work in multi-user applications. Saving a initial copy and locally generated changes will work well for single user worlds but will fail for multi user worlds.

In the singe user/private copy case we require script authors to write save/restore methods. This is because we believe that the degree of persistence is different for different applications. Some do not need it at all, while others may need something as complicated as a database to store the entire state of the world and the application. In the multi-user/shared world case, persistance will be built as a meta-layer above a set of heterogeneous mechanisms, some in browsers, some in servers (if used) and some in the network protocols. Our position is to keep VRML as simple as possible. You can do that through scripts.


  1. Prototype proposal
    Incorporates SGI's prototype proposal into the MSS proposal.
  2. Latest behavior proposal
    The latest versionof the MSS proposal.
  3. Sony's extensions to current VRML1.0 standard
    Our extensions to VRML with examples
  4. An O-O perspective on VRML
    This paper presents a way of viewing VRML that makes life easier.
  5. Mitra's comments on the SGI proposal
    Some feedback from Mitra on the SGI proposal
  6. Mitra's comments on the SGI critique of the MSS proposal
    This is Mitra's comments on the SGI critique of the MSS proposal.