>Performance > >Giving the person looking at VRML worlds a good experience is our number 1 >priority. And we believe that the number 1 problem with VRML today is >performance-- VRML must run well on everything from a PC to a RealityEngine2 >to truly be successful.There are two major problems - performance and functionality, unfortunately sometimes they are at odds with each other
>We believe that the more information given to the browser, the better the >browser will be able to optimize the scene. Some specific features that will >lead to bad performance: > >Arbitrary effects on scene > >The MSS proposal allows a script to resolve any named node during the >execution of the script. Because the browser does not know which fields of >which objects a script might change, it will not be able to do any of the >following things: > > 1. Convert the scene graph into a different internal representation better > suited for whichever rendering library is being used. > 2. Decide not to run the script because its results are irrelevant (for > example, a script driving an animation that cannot be seen does not > need to be run). > 3. Decide which parts of the scene can be optimized based on which parts > it knows will not change.There are two levels of optimisation that Gavin has discussed, the first is optimisation based on knowing what can be changed, the second is optimisation by knowing what changes what. It looks like cases 1 and 3 above fit into the first category, this category of optimisations is just as possible under our proposal as under SGI's, the difference is that under SGI's proposal you can also optimise out anything that doesn't have a logic node connected to it - however you won't be able to do this if you allow run-time addition of connections anyway. Also, case (1) above is also used as an argument against SGI's proposal since the addition of Logic nodes inside of fields means a much tighter coupling to the Open-Inventor scene graph, which will hurt non-OI browsers. Case (2) is an example of the second sort of optimisation, something most browser writers I've talked to assert they won't do anyway, especially since many scripts will run asynchronously, or need to change state in response to an event whether or not they are visible. In our proposal, the optimisation is handled at the script by adding CULLIN/CULLOUT events which allow a script to minimise or ignore events.
>It is naive to expect that only a few nodes in the scene will be given >names; many authoring packages give every single object a name (either >user-defined or system-generated) to allow the author to refer to objects.This needs addressing, I believe it is addressed to a certain extent by the prototyping proposal which allows the internals of a section of scene graph to be hidden, however its also a problem with your proposal if it supports dynamic connections.
>The MSS proposal adds the CULL_IN/CULL_OUT and LOD_IN/LOD_OUT events to try >to address the irrelevant script problem. Script creators will not do the >right thing with these events when it is much easier to do nothing. Scripts >will work well until worlds start getting larger than the tiny, toy-sized >worlds common in the VR community today. The SGI proposal gives browsers >enough information so that they can take care of the irrelevant script >problem automatically.Script creators are as likely to do the right thing as geometry creators are. Once the SGI proposal supports dynamic worlds it will have the same problems with this as ours does.
>Excessive script invocation > >Exactly when scripts are executed isn't specified in the MSS proposal, but >assuming scripts are executed whenever an 'event' happens, their proposal >will execute script methods more often than necessary. For example, a script >that is detecting and responding to the modification of several fields >(using FieldEvents) will, I assume, be executed whenever each of the fields >change (since each of the FieldEvents has a separate actionMethod). If two >of the fields change (perhaps because of the execution of some other >script), then the script will be executed twice. In the SGI model, a script >that depends on two inputs will (by default) be executed only once, even if >multiple inputs have been changed since the last time the script was >executed.This is a good point that needs addressing.
>The same is true for single inputs that change multiple times in between >execution of the script; by default, the script is run only once. In the SGI >proposal, the author must tell the browser that they care about every single >change to an input or set of inputs to get a script executed multiple times. >In most cases a script does not care about the history of changes to things >it depends on, it only cares about the current state of the things it >depends on. For example, a script that keeps an object tracking the mouse (a >DragSensor in the SGI proposal, a Drag callback in the MSS proposal) will >typically not care about intermediate mouse positions, but instead will only >care about the latest position.This is not handled in the SGI proposal, it needs to be clearer what happens when multiple events occur within one execution frame in your proposal.
>Executing scripts multiple times is not a really big problem until you get >chains of scripts that depend on the values set by other scripts (which >depend on values set by yet other scripts...). In those more complicated >cases, executing scripts multiple times becomes a HUGE performance problem, >since authors can easily create networks that have O(2^N) behaviors, where N >is the number of chained scripts (it is actually M^N, where N is the number >of chained scripts and M is the average number of values that each depends >on).This is a good point, but is equivalent to the problem in SGI's proposal of passing all the inputs to a script whenever one of them changes. It also assumes that executing a script is significantly more expensive than the internal work done in a logic node, in complex cases it is easy for a script to use the event handlers to store values, and then use a FRAME event to make all the results happen at once.
>example deleted > >TimerEvent > >The MSS proposal has a very discrete model of time. A TimerEvent may be >added to get a method called every N seconds (where N is a floating point >number). Like the CULL_IN/etc events, a well-behaved script will have to be >written carefully so that it is not constantly being executed because of >TimerEvents going off; the script will have to remove the TimerEvent when >stopped, and add the TimerEvent when re-started.This is even worse in SGI's proposal, where a script will be executed once per execution cycle with the new value of time. Timer events will cause FEWER not more executions if they are less than the frame rate. Also, removing TimerEvents is trivial in our proposal, I can't even figure out how it would be done in SGI's proposal since the timer has to be hard-wired to the Logic node which will execute every time its input changes.
> >Time is continuous in the SGI proposal; time-driven objects are >(conceptually) evaluated constantly. The fact that this isn't possible in >practice and time must be discretely sampled is an (important) >implementation detail that VRML authors will not, in general, need to be >aware of. The SGI proposal's TimeSensor (roughly equivalent to the >TimerEvent) has explicit start and stop times, and all user-input is tagged >with the time that the user input event occured. Forcing authors to deal >with time as discrete events will hurt performance (since authors will >explictly have to register/unregister TimerEvents to control when the events >start/stop), and will cause problems as VRML is integrated with truly >continuous media such as sound.See the above comment, but dealing with continuous time is not an issue, for example the script can register a FRAME event, and then read the time from the _Timer pseudo-node.
>Re-usability > >We believe that the SGI approach will result in object/behavior components >that are more re-usable, for the following reasons: > >Compiled-in connections > >In the MSS proposal, a script explicitly names the nodes and fields which it >sets and gets. This approach make the script not usable with nodes and >fields that have different names, i.e. the script cannot be reused. Thus, >the author is forced to write a new script just because they want to modify >the translation and rotation fields of a Transform named "Foo" when they >have a perfectly good script that modifies the translation and rotation >fields of a Transform named "Bar". Connections in our proposal permit us to >make this binding at authoring time (and not at the script writing time).This is not correct, their are two simple solutions in our proposal. 1) Pass the name of the object as a parameter. 2) A script attached to an object can resolve names of fields of that object. (this may not have been clear in earlier versions of the proposal).
> >The "actionOn" field appears to be an attempt to address this, but will fail >as soon as a script needs to modify more than one object (e.g. a script >modifies the "actionOn" object and the object named "Bar", and I'd like to >re-use it to act on two other, different objects).This is identical to the case with a logic node, in both cases you have to pass the script the name of the object to be modified.
>Fragile name problem > >When you rename a node, you must change all scripts that refers to that node >otherwise you will encounter an error when you try to run the script. With >connections, you still have to change the connections but you can detect >dangling connections at load time rather than at run time. >We believe it is best to detect problems as early as possible, and believe >that explicit connections in the scene will allow authoring programs to >bring problems to the attention of the VRML author. If the connections are >"hidden" inside scripts, the author will not know there is a problem until >the script is run.This assumes that most authoring in the future will be graphical, not a mix of graphics and programming. If the "programming" is done by a graphical authoring tool, then it will have exactly the same opportunities to make sure all the connections are made. The real flaw is that this checking IS done at load time, something that will fall down badly in dynamic worlds.
> >Access control: anonymous nodes > >Anonymous nodes (nodes with no name) gives the author a certain minimal >amount of access control; you can only make changes as specified by the >connections, but nothing else. Because the only way to change anything in >the MSS proposal is by looking it up by name, if you can change part of a >node you can change all of it.Not correct, in our earlier proposal you could only change via the "Interfaces", as the proposal has been rewritten to use Gavin's "Prototypes", the same constraints apply to what the script can modify, but once again - as soon as you have dynamic creation of links you'll have the same problems in SGI's proposal.
>Persistence > >The MSS proposal does not address the persistence requirements that users >will require VRML browsers to support. As VRML worlds get large, >interactive, and interesting, it will be important for users to be able to >"save the state of the world". For example, imagine a single-user VRML >adventure game (something like Myst, perhaps) that takes a long time to >solve. The user will have to be able to save where they are in the puzzle to >come back later.With asynchronous scripts this will be needed anyway, in our proposal the script gets a WORLD_OUT event, which allows it to save any state it wants - either internally in a file, or by writing back to variables inside the scene. As worlds become large, it would be a naive approach to save all the state of every object.
>In the SGI proposal, we assume that "the state of the world" is available to >the VRML browser-- that the browser has enough information to determine what >has changed, and when the user quits the browser or saves a "bookmark" to >come back to later, the browser will be able to do something like: >Remember the URL for where the world was fetched >Remember the current view >Store a list of changes that the user has made to the base world > >When the user re-starts or goes back to the saved bookmark, the browser >will: >Fetch the 'pristine' world from the URL >Apply the changes that the user made to the world >Set the current view > >Note that a similar process must also occur if the world is very large and >the browser needs to unload part of the world to make room for some other >part; any changes to the part of the world being unloaded will have to be >remembered to maintain the illusion of a continuous, very large virtual >world.Again - this is nto a problem in our proposal, the events are available to save whatever state is needed.
>In the MSS proposal, not enough information is available to the browser to >properly save and restore the state of the world-- this could be rectified >by either requiring script authors to implement save/restore methods, or by >adding fields/variables that the script can read/write and that the browser >is aware of. However, it isn't clear exactly where those fields/variables >would be stored, since scripts are associated with Separators (the script is >not a separate object like SGI's Logic node).Note - that this is because the earlier versions of the proposal were based on the change to Separator which was proposed by SGI, and later withdrawn. In both SGI's and our proposals, a script that maintains internal data will have to save that data into the scene graph, or somewhere else.
>It is possible to write Logic nodes using the SGI proposal which also have >this problem; however, the SGI proposal will make it much more natural for >authors to create well-behaved Logic nodes that can be correctly >saved/restored by browsers. > >---------------------------------------------------------------------------- > >Overloading the Scene Hierarchy > >The MSS proposal associates scripts with Separators in the scene graph. We >believe that overloading the meaning of the scene hierarchy in this way will >make it more difficult to create worlds with behavior. > >In the SGI proposal, the position of a Logic node in the scene hierarchy is >irrelevant (in fact, Logic nodes that "hang off the side" of the scene >hierarchy work perfectly well). There are often situations in which it >doesn't make sense for a Logic node to be any particular place in the scene >hierarchy. > >For example, imagine a script that detects when three toggle button objects >are all turned on at the same time; when they are, the script turns on a >light, opens a door, and starts a sound. In this example, there is no single >object with which the script should be associated; putting the script on any >of the three buttons, the light, the door, or the sound would be wrong.There are very few cases where a node doesn't have a good home for it, but in this case both SGI's and our proposals have to put the script in an arbritrary place and link it to the other places.
> >---------------------------------------------------------------------------- > >Key differences > >Given these issues, we identify several key issues that we think distill the >differences between the two proposals: > > 1. Logic/scripts as a separate node versus logic/scripts associated with > Separators. Because it is sometimes not possible to identify a > particular Separator with which a script should be associated, we > believe it is better to have Logic/scripts be distinct nodes.This is not a relevant difference, our proposal was written this way because of SGI's proposal for a change to Separators, it can (and has) been written either with separate Script nodes, or by putting them on Separators.
> 2. Sensors as nodes or sensors done as messages/callbacks/events. We > believe that using the same mechanisms for everything results in a > cleaner, smaller, easier to understand and use system. The > event/callback model adds extra complexity (note that the MSS proposal > already has the equivalent of the SGI's connection proposal, hidden as > the "tiny language" of the "actionMethod" field).Many people believe that the logic node way of doing things adds extra complexity compared to an event/callback model they are familiar with - this is a religious issue :-)
> 3. Explicit connections versus implicit name lookup. We would like the > get/set paths between objects to be known to the browser at read time, > so that the browser can intelligently optimize and re-organize the > scene graph for maximum efficiency, both for objects that it knows > might change and for objects it knows will never change. We allow > arbitrary changes to any or all of the scene graph, but require world > creators to explictly state which parts of the scene a script will be > editing (a script writing into a NodeReference that is inserted at a > particular place in the world). Because the MSS proposal allows any > script to look up arbitrary (either named or prototyped) nodes, > browsers will have to assume that there is an implicit connection > between every script and every named or prototyped node.This is a fundamental difference, our proposal assumes worlds will become dynamic, something that isn't really addressed in SGI's proposal.
>Many of the issues raised in this document are subtle, and become apparent >only after a system has been implemented and used. They represent hard-won >knowledge gained by the design and implementation of 3D products such as >Open Inventor, WebSpace Navigator, WebSpace Author, IRIS Inventor, IRIS >Performer and IRIS Annotator.And the hard-won knowledge of the programming world, has been that programming works much better with an event-driven model than with hard-wired data-flow model.
- Mitra