Game Development Reference
In-Depth Information
the removal of collision geometry that has been exported to matching API-
specific files earlier in the asset pipeline but still exists in the source file;
the removal of editor-specific nodes representing cameras and other UI ele-
ments that exist within the scene.
Post-insertion conditioners, on the other hand, perform tasks that require knowl-
edge of the context into which a file's contents is dereferenced. Such tasks might
include
generating unique IDs with which to reference each node;
propagating transforms to the dereferenced subgraph so that the nodes are
positioned and oriented relative to the subgraph's immediate parent in the
scene;
collapsing long columns of redundant nodes that contain no data beyond
transforms and only a single child. These are often created during the
dereferencing process and artificially increase the depth of the scene.
O ine processing. The flexibility of the architecture allows it to be used in con-
structing not just various engine configurations but also tools that work upon the
same data set. Such tools can be used to process or analyze scene data oine
using a very different set of aspects and conditioners from those involved in the
game itself.
These can be built into the asset pipeline to automatically process data ex-
ported from authoring programs and create files optimized for loading directly
into the game on a range of target platforms.
1.6
Implementation
One of the key principles of this engine design is the construction of scene nodes
through data aggregation rather than explicit classes within the engine's code.
Much of the interaction between the aspects and the core scene will be informed
by the implementation of this principle. It is therefore worthy of more in-depth
discussion.
Nodes are in essence containers that associate a description of each attribute,
a name and a type identifier, with a pointer to the relevant data. The Standard
Template Library (STL) provides a variety of containers with different properties
and a shared interface (see Listing 1.1 ) , making it relatively simple to choose
one to fit any given situation [SGI 11]. In this instance an associative container
like a map or set (or multimap/multiset if you want to allow duplicate attribute
names) would be an obvious choice because it features easy searching of content
and does not require elements to be stored in contiguous memory, which can
cause excessive fragmentation when inserting/deleting contents.
 
Search Nedrilad ::




Custom Search