To enable dynamic configuration of behavior-rich 3D application content, a specific organization of the content is necessary. In the Flex-VR approach, content is organized based on a novel structuralization model, called Beh-VR.
VR-Beans
In the Beh-VR model, a 3D scene is composed of software elements called VR-Beans. Technically, VR-Beans are objects, implemented as standard Script nodes, but conforming to a specific convention. Conformance to this convention enables combining arbitrary sets of VR-Beans into technically correct 3D scenes and provides means of inter-object discovery and communication. Beh-VR applications are fully compliant with existing 3D content standards, and therefore can run in standard 3D browsers.
Each VR-Bean consists of at least one scenario script, an optional set of media components and an optional set of parameters (Fig. 5.2). The scenario script is the main element controlling each VR-Bean. Scenario scripts are programmed in a high-level XML-based programming language, called VR-BML (Behavior Modeling Language) [29, 31]. Each script contains specification of appearance and behavior of a single VR-Bean object. Scenarios describe what happens when the object is initialized, what actions are performed by the object, and how the object responds to external stimuli. In some cases, there may be several different scenarios controlling the VR-Bean depending on the presentation context.
Fig. 5.3 A Beh-VR structure and the resulting 3D scene
A VR-Bean can contain a number of media components, which are used for representing the VR-Bean in virtual scenes. Examples of media components are 3D models (X3D/VRML), images, audio objects, video sequences, and texts. Based on the available media components, a behavior script may create any number of scene components, which are geometrical or aural manifestation of the VR-Bean in a virtual scene, but there may be also VR-Beans that do not manifest themselves directly.
A VR-Bean can be also associated with a set of parameters. Parameters are characterized by a name, a type (integer, string, Boolean, etc.), and a value. Parameters can be read by scenario scripts and can be used in determining appearance or behavior of objects.
Structure of Beh-VR Scenes
A Beh-VR scene is created dynamically by combining independent VR-Bean objects. Each VR-Bean object is controlled by a VR-BML behavior script (Fig. 5.3). A behavior script may load any number of media components into the virtual scene, thus creating scene components that are geometrical, aural, or behavioral manifestation of the VR-Bean. Scene components may be created during the object initialization phase or later during the object lifetime. Objects may also freely change their representations at any time. A scenario can create and destroy scene components and can communicate with the scene components within a single VR-Bean by sending and receiving events to/from the components. Each script can control all scene components it has created but has no direct influence on other scene components.
Since the contents of a Beh-VR scene is composed ad hoc, communication between objects becomes a critical element. Meaningful communication requires identification of objects present in the scene, well-defined roles of objects, and existence of technical means of communication.
Identification of objects is possible due to a hierarchical system of categories and a process of registration and discovery. Each object may be registered in an arbitrary number of categories. The categories also define roles of objects in the scene. An object assigned to more than one category plays several different roles in a scene.
Communication between objects is realized using two mechanisms: public values and method invocation. Public values are named public expressions that can use variables and events from a single VR-Bean. Each VR-bean can explicitly read public values, can be notified when such a value changes, and public values can be directly assigned to input events of scene components.
Method invocation can be performed on single objects, lists of objects, and the whole categories. A method consists of a sequence of VR-BML commands, which may change the state of a VR-Bean, alter its representation in the virtual scene, invoke other methods, etc. Each method may have any number of parameters. Formal specification of parameters is provided in the method definition, while actual parameter values are set in a method call.
The VR-BML Language
The VR-BML language is based on XML, which is the de-facto standard for creating new languages in the domain of multimedia and—particularly—3D content. Most new 3D content standards such as X3D, 3D XML, and COLLADA are based on XML. XML is easy to interpret, the existing software may be used for parsing and processing of the program code. The structure of XML programs may be verified against their formal specification in form of XML Schema [39].
The VR-BML language consists of a list of commands, a specification of the program structure, and expression grammar for attribute values. The VR-BML language uses the basic syntax of the X-VRML language [34, 35] (Chap. 4). This includes the expression evaluator, which enables using constants, variables, operators and functions in command parameters. Also, commands of the X-VRML Core Module such as assigning values to variables, conditional statements, loops, and logging are supported in VR-BML.
There are two main types of commands in VR-BML: structuring commands and instruction commands. Structuring commands provide the necessary structure of a VR-BML script, which enables to correctly interpret the instruction commands. Examples of structuring commands are: Scenario, Initialize, Method and Action.
List. 5.1 Structure of VR-BML scenarios
Instruction commands are VR-BML commands that perform some operations, such as loading an X3D model into the scene (Load), moving a component to a specific location (MoveTo), and calling a method (Call). Most commands require parameters, which may be provided as constant values or expressions containing references to variables, public values, and events generated by scene components.
The VR-BML language can be used to program scenario scripts of particular VR-Bean objects as well as content patterns describing structure and scenario skeletons for the whole presentation spaces (Sect. 5.5).
Scenario Scripts
The structure of VR-BML scenario scripts is presented in List. 5.1. Each script consists of three sections:
• the Initialization section,
• a list of Method definitions,
• a list of Action statements.
The initialization section is executed first—just after the object is created in the virtual scene. It typically contains all commands that are necessary to initialize the object in the scene, such as loading components and positioning them in space, activating selected components in the virtual scene, registering the object, and initializing variables.
A scenario script may contain an arbitrary number of methods, which are unambiguously identified by their names. A method definition provides the set of formal parameters and their default values. Methods can contain instruction commands, influencing the state, appearance, and behavior of the object in the virtual scene. Methods can be explicitly called by other methods, initialization sections, and actions of the same or other VR-Bean objects.
A scenario may also contain any number of action definitions. Actions are executed implicitly when specific conditions occur in the scene. Similarly as in the case of methods, each action is identified by a name, which enables overriding inherited actions. Each action definition specifies a condition, which must be satisfied to trigger the action, the time between action executions, and the maximum number of executions. Scenario scripts can inherit methods and actions from scenario classes that form inheritance hierarchies.
The most important commands used to build VR-BML scenarios are described below. The list is not complete, omitting less frequently used commands. Also, the set of commands may be extended in particular VR-BML implementations.
Scenario The Scenario command is the main element of each VR-BML scenario script. Each Scenario command is executed separately, in parallel to other scenarios (e.g., through the use of threads). The command has one optional parameter extends which provides the name of a scenario class. The Scenario element can contain only three types of elements: Initialize, Method, and Action (List. 5.1).
ScenarioClass The ScenarioClass command is used to create classes of scenarios. The structure of a scenario class is the same as the structure of a scenario (List. 5.1). It may contain the initialization section, a number of action statements and a number of method definitions. Additional mandatory parameter name provides the name of the scenario class, and the optional parameter extends provides the name of a scenario super-class.
The initialization section defined in a class is executed before initialization sections of any scenario or subclass that inherits from this class. Methods and action statements are inherited by subclasses and scenarios, but can be overridden by method definitions and action definitions in subclasses and scenarios. Methods and actions are unambiguously identified by their names—there is no method overloading based on the parameter sets.
Initialize The Initialize command forms initialization section of a VR-Bean. The initialization section is executed once for each VR-Bean object when the object is created in a virtual scene. The initialization section typically contains all elements that are needed to build the VR-Bean and to set-up its initial state. Typically, the section contains commands for loading the scene representation of a VR-Bean, registering the VR-Bean in the virtual scene, and setting initial presentation attributes. The Initialize command may contain all instruction commands of the VR-BML language (e.g., Load, Set, Register, or Activate).
Method Each scenario may contain an arbitrary number of Method statements. Each Method statement defines a method, i.e., a fragment of VR-BML code, which is executed when explicitly called by the same or another VR-Bean. The name of the method is provided in the name attribute, while formal parameters of the method are provided in the params attribute. Each parameter has a default value, which is used when a method call does not specify value of this parameter. The result parameter provides the name of a variable that will hold the value returned by the method. The returned value is defined using optional Return command inside the method code.
Example method definition is the following:
Action Each scenario may also contain an arbitrary number of Action statements. Each Action statement represents an action, i.e., a fragment of VR-BML code which is executed asynchronously when a specific condition is satisfied.
Execution of an Action command starts when the condition defined in the condition parameter is satisfied. The maximum number of executions is defined in the count parameter. Count equal —1 means that there is no limit. If the condition is still true, the action is triggered again after the time provided in the time parameter. If the time parameter is equal —1, the action is repeated immediately after the previous iteration. Example of use:
Content Patterns
Content patterns can be assigned to presentation spaces (Sect. 5.5.1). Patterns simplify design of complex presentations by defining categories of objects and providing skeletons of scenarios for particular categories of objects. A content pattern defines the following:
• a list of categories of objects that can be assigned to this presentation space together with their default scenario definitions;
• a list of subspaces of the presentation space together with their default content patterns.
The overall structure of a content pattern definition is presented in List. 5.2, while the meaning of particular commands is explained below.
Pattern The Pattern command defines the overall content pattern. It has just one parameter: name, which enables presentation spaces to reference this pattern. The Pattern element may contain two types of elements: Category and Space .
Category The Category command defines a category of presentation objects that can be assigned to a presentation space associated with this pattern. Categories define roles and behavior of objects in the presentation space. Categories are application dependent. Examples of categories include Artifact, Scenario, Narration, and Camera.
List. 5.2 Structure of VR-BML patterns
Space The Space command defines a subspace of the presentation space. The subspace is described by a name, three spatial transformation parameters: translation, rotation, and scale, relative to the current presentation space, and a content pattern. The pattern can be referenced by a name from a library of existing patterns or defined directly in the Space element.
Object Discovery Commands
Since the contents of a Beh-VR scene is configured after the behavior scripts are programmed, there must be a mechanism of discovering what objects are in the scene. This is achieved by using the process of registration and discovery.
Register The Register command enables registering the current VR-Bean object in one or more categories. Categories form a hierarchical catalogue, enabling VR-Beans to discover what other VR-Beans are in the scene and what their roles are. The Register command has two parameters: category and name. The category parameter specifies a list of categories in which the VR-Bean should be registered. The name parameter specifies the name by which the VR-Bean will be registered in these categories.
Retrieve The Retrieve command is complementary to the Register command and results in retrieving the list of VR-Beans that are registered in specific categories. The Retrieve command has two parameters: category and var. The category parameter provides the list of categories. If a category is followed by a “+” sign, all sub-categories of this category are also taken into account. The var parameter provides the name of a variable that will contain the list of retrieved VR-Beans. Example of use:
