Game Development Reference
In-Depth Information
Node
Node
Node ID
Node ID
GetData<Matrix>(“wM”)
Matrix, wM
Matrix, wM
AccessPointer<Matrix>
Matrix, Local
Matrix, Local
Ref, Geometry Inst.
Ref, Geometry Inst.
Ref, Material Inst.
Ref, Material Inst.
Figure 1.4. Data access request
Figure 1.3. Node composition.
Each node within the scene graph stores a list of data attributes, identified
by name and type (Figure 1.3). The meaning of a node and the makeup of its
attributes are not restricted or defined by the engine design, allowing for any
number of meanings to be expressed as required.
A node might describe a physical object, such as a light or camera from a
3D scene. Likewise it might describe a bone from a character's animation rig or
a mouse cursor. It may even represent an abstract concept, such as a victory
condition, within the rules of the game. The meaning of each node is determined
by its relative position in the graph, its attributes, and how those things are
interpreted by the aspects that make up the rest of the engine.
1.3.3 Data Access
One consequence of implementing nodes using aggregation is that there is no
interface providing a direct means of accessing the data contained within a node.
Instead access must be requested, the calling code querying the node to see if it
contains an attribute with the desired name and type. The node then returns
an access pointer templated to the correct type and increments a reference count
(Figure 1.4).
In a multithreaded environment, safe access through these pointers, and to
the rest of the core elements, requires a mutual exclusion (mutex) to be ac-
quired by the calling thread. In this circumstance it is often more ecient for
aspects to duplicate any relevant data and operate on an internal representa-
tion of the object that can be synchronized with the core scene graph at defined
points.
 
Search Nedrilad ::




Custom Search