Ygdrasil is built in C++, around SGI's IRIS Performer visual simulation toolkit and the CAVERNsoft QUANTA library. Performer provides a hierarchical representation of the virtual world database, called a scene graph. The scene graph is a tree that encodes the grouping of objects and nesting of 3D transformations, and provides tools for operations such as switching elements on or off.

Ygdrasil focuses on constructing dynamic, interactive virtual worlds, so in addition to the basic graphical data as used in Performer, its scene graph nodes can have behaviors (i.e. functions to update the nodes' state) attached to them. Tying the behaviors to the nodes has made it easy to assemble large worlds from simple components. A behavior is added by taking one of the core classes, such as a transformation node, and deriving a subclass with the new features. Individual node classes are compiled into dynamically loaded objects (DSOs), so that they can be rapidly added to a world or modified. The system includes a number of pre-made classes (also DSOs) that implement common virtual world tools - sounds, users' avatars, navigation controls, triggers that detect when a user enters an area, etc. These built-in tools simplify the quick construction of many basic applications.

The Ygdrasil framework further extends the scene graph to be shared across the network. The concept of a shared scene graph has also been explored by other recent VR development systems, such as Avango (formerly known as Avocado). In a shared system, each participant has his own local copy of the common scene graph. Node data, such as lists of nodes' children, transformation matrices, and model information, are automatically distributed among these participants as the data changes or when participants first join the shared world.

In Ygdrasil, the scene graph is shared using CAVERNsoft's distributed database model. The data that are to be shared for any node in the scene graph are stored in the database keyed by the node name and the data members' names. The scene can be dynamic, so whenever a client first learns about a new node (by a reference to the node's name), it looks up the node and its type in the database. The client can then create an appropriate local copy of the node, and retrieve all the other data as needed.

Each particular node is considered to be owned by the host that creates it. The owning host maintains the master version of the node, and executes any behavior associated with it. All other hosts will create proxy versions of the node, and only receive data for it through CAVERNsoft; they do not directly modify the node (they can however send messages to the master copy to request changes). The proxy version of a node is typically of the simpler parent class type, without the added behavior code. Thus, if all of the main behaviors for a virtual world are executed by a single master version of the scene, remote sites can join in this world without needing anything beyond the standard, core node types.