Xj3D External Interaction Component

Intro

Applications are able to create instances of browsers and manage the contents of the browser through the use of specifically designed external APIs. In VRML97 this is the External Authoring Interface, and for X3D, it is a component of the Scene Authoring Interface. External interactions form a separate code path from their close relative the scripting interactions. The principle difference is that an external interaction is not a direct part of the scene graph, where the scripting is. This component contains all of the implementation work needed to provide external access to the scene graph.

Requirements

There is a lot of similarity between the two specifications. The major requirement of this component is to provide support for the following standards: Since the codebase is pure Java, the only language that is required to be supported is Java.

Analysis

The requirements of both specifications are fairly similar, only the details are different. In addition to the basic functional areas required by the APIs, there are two major design features that must be considered - request buffering and the need to implement a complete browser.

To provide scripting support, the Browser Core component is utilised. Around this will then be built a common request buffering system. The EAI specification was not very precise about when events that have come from the buffering system are to be integrated into the event cascade processing. X3D is much more precise about this, so where needed, the implementation will follow the X3D requirements and apply those to the VRML97 model.

Structural Overview

 The basic code can be separated into three parts - the implementation of the interfaces and classes required by the specifications, the buffering mechanism and the processing of the buffered events within the VRML event model.

Code Layout

The majority of the code lies in a single parent package - org.web3d.vrml.scripting.external. Under this package there are separate packages for the EAI, SAI and the buffering system. Under each of these there are more sub packages as needed to keep the implementation clean.

Packages for the spec-required APIs are kept as a separate area under the required packages - vrml.eai and org.web3d.x3d.sai respectively. These two packages are as-is. The Xj3D codebase makes no modifications to them at all beyond providing sufficient Javadoc documentation.

Runtime Processing

The runtime semantics are based on the X3D specification for the external interactions because it is much more precise about when the events from the external code are to be applied to the event model processing. While VRML97 stated that non-buffered events should be processed immediately, it never really defined how immediate that should be. For example, if the request comes in to change the transform of the camera while the camera position is being read by the rendering engine, you will end up with very strange results. The X3D spec is more precise on the definition of "immediate" - which is, (roughly) at the start of the frame processing but before the rest of the event model. IOW, external events are treated like sensor input.

As the user code is generating events to send in from the external application, they get placed on a buffer. As the internal event model processing evaluates, it reads events off the buffer. If the user has called beginUpdate(), then there would not be anything to read from that buffer as the begin call acts like a gate - effectively creating a two-stage buffer of events - those buffered at the client end, and those waiting for the next time the event model needs to process them. If the user has not called beginUpdate() then the events ignore the first stage and get placed straight onto the internal queue ready for processing.

Extending the Code

 TBD.

References

[ Xj3D Homepage | Xj3D @ Web3d | Screenshots | Dev docs | Dev Releases | Contributors | Getting Started ]
Last updated: $Date: 2004-04-30 04:50:26 $