Visual Content in Digital Spaces
From Digital Spaces
Contents |
Step 1 - Parsing the .Space
The .Space file specifies what capabilities will be required for this Space. Commonly used are SGManager, 3D Visuals, GUI, User Input and Scripting. The .Space file is also responsible for passing initial configuration data to these capabilities.
Step 1a - Data Resources
The .Space file instructs the DataResource Manager where to find resources. These usually represent files in folders, but could be other containers, including files on a HTTP server. These resource locations will include all resources specified in other files, such as models, material descriptions, textures, skeletons, sounds, or other types of resources. (NOTE: Due to current implementation limitations, Script files do not load through the DataResource manager.)
Step 1b - Scene Files
The .Space file instructs the Scene Graph Manager (SGManager) what .Scene files to load. These files specify the Scenegraph, the heirachal description of resources used to render the visual and physical aspect of the Space.
Step 2 - Parsing the .Scene
The .Scene file contains information about the visual and physical aspects of the Space. This includes global information (ambient lighting, shadow techniques) as well as a hierachal node/renderable structure. This file is interpreted and used to construct Scenegraph objects and their appropriate representations. Each Component that provides Scenegraph representatons (such as 3D Visuals or Physics) is responsible for parsing the appropriate information from the .Scene file, with the SGManager deliberately limited to producing a heirachy of objects that can be one or more of: Heirachal (has children), Movable (has position/orientation/scale) or Renderable (an inert object, such as a static model).
SGManager Design
In the SGManager design, all Renderable objects (such as models, particle systems, and physics collision geometries) are contained within Heirachal objects. The most common Heirachal object is the Scenenode. Scenenode's are Heirachal, Movable objects, meaning the can have children, and they can have position/rotation/scale, which will be applied to their children.
A special Scenenode, the ROOT Scenenode, will always exist. All objects in the Scenegraph are children of this Scenenode. The ROOT Scenenode is fixed at Identity, meaning, a position of 0,0,0, a rotation of 1,0,0,0, and a scale of 1,1,1. (Rotations are measured in Quaternions, instead of Matrixes, as used in some other systems.)
Generally, objects in the Scenegraph will have representations in other Components. For example, Scenenodes will have a corresponding OGRE SceneNode, and may have a Physics Body.
The children of a Scenenode may be other Scenenodes, or other types of object. The most common is the Entity. This is conceptually matched to a model, and is created by loading a model file by the 3D Visuals Component. Due to the flexibility of the model concept, an Entity may not only be a Renderable object (a static object that is part of the scenegraph but doesn't alter in any way) but it may also be a Heirachal object, if it has a skeleton. If a skeleton is specified by the model file, then the bones of this skeleton will be made available through the Scenegraph as Heirachal Movable objects.
Another common Renderable object is a Shape. These conceptually match primitive collision shapes used in the Physics Component. These are purely Renderable objects, but work in conjunction with a parent physics Body (which conceptually matches a Scenenode, if specified).
At this point, you may have realized that a Scenegraph object can have more then one Component representation. This is the purpose of the SGManager, to co-ordinate between Components and tie their functionality together into a consistant scenegraph. For example, a Scenenode (a Heirachal Movable object) may have both a OGRE SceneNode representation and a Physics Body representation. The SGManager monitors the Physics Body (through an abstract interface that removes any need for SGManager to know about Physics Bodies) and any changes made to its position/orientation through the physics simulation are then pushed to the OGRE SceneNode representation. In this manner, any child objects of this SceneNode will reflect the changing state of this body.
While the SGManager provides a co-ordinated interface to objects within the Scenegraph, at all times it remains possible to access the objects provided by the other Components. For example, while none of the SGManager objects have a concept of weight, the physics bodies representing a Scenenode does, and the Scenenode object may be converted to a Physics Body object and its additional properties accessed as appropriate.
Scenegraph Representations
The previous section discussed the relationship between the SGManager and other Components in general terms.
Components that wish to provide representation of Scenegraph objects implement the DInterface DISGRepresentative (? check ?). (NOTE: A DInterface is an abstract interface used within Digital Spaces to allow binary compatible communication between Components which may be implemented in a variety of methods, such as different compilers and in theory different languages.) This DInterface allows the SGManager to discover what types of objects the Component supports, by string based name. When the SGManager parses the XML within a .Scene file, the value of each XML node (e.g. <node> or <entity>) is used to query a Component for support. If the Component specifies it supports this type of object, the XML from the .Scene file is passed to the Component, to be used in constructing and configuring the object.
Due to this system, the XML used within the .Scene file cannot be formally specified. The types of nodes permitted will vary as Components are developed, and the XML structures, both child nodes and node attributes, will change as well. See (? check the wiki ?) for a list of the currently supported XML node types, and what configuration parameters they support.
The SGManager treats some XML nodes as special. These are properties that are considered to apply to all representations of a Scenegraph object. At the current time, these are limited to <position>, <orientation> and <scale> (? check ?). These properties should be ignored by the Component constructing the Scenegraph object representation, as they will be set by the SGManager after object construction.
Another aspect that is important is that the Component providing Scenegraph object representations should use a minimal amount of configuration data to construct the represtative object. Once an object is constructed, and given to the SGManager as a generic interface DISGRepr (? check ?), the object will then be configured by passing it the same XML as was passed to the Component (as a DISGRepresentative). The reason for this is two fold. One, this encourages the object configuration code to be contained within the object, encouraging Object Orientated design, and Two, this allows as many properties of the object as possible to be altered at later stages. Any property that can only be specified during construction reduces the flexibility and utility of the Component to the end developer.
