User guide

178
Core Concepts with Geolib3
There are three core concepts in Geolib3 that pertains to the Op API: the Runtime, Ops and Clients. In the sections
below, we'll address the host of the system - the Runtime - and the services it provides before looking closely at Ops
and the concept of the Client, and its use.
Differences Between Geolib2 and Geolib3
Geolib2 did not have a persistent scene graph data model. Conceptually, the entire scene graph is reconstructed on
every edit. Conversely, Geolib3s OpTree is persistent, allowing for inter-cook scene data re-use.
Geolib2s scene graph was traversed using an implicit index mechanism, for example getFirstChild(),
getNextSibling(), with scene graph location names determined by the name attribute. In Geolib3, children are
natively indexed by name. Thus, in Geolib3 you can selectively cook a location, by name, without cooking any
peers. Consequently, the name attribute is meaningless. However, this also implies that locations cannot rename
themselves (you can rename children, however).
Geolib2 was not amenable to either asynchronous or concurrent evaluation. Geolib3 supports both of these
features.
The Runtime
The Runtime is responsible for coordinating Op execution, and provides a few key services:
A means of configuring and modifying the persistent OpTree. This includes creating instances of Ops, connecting
Ops to each other, and providing them with arguments to determine their behavior. Within Katana, artists interact
with nodes rather than the OpTree directly. There is roughly a 1:1 correspondence between nodes in the node
graph and Ops in the OpTree.
The ability to register your interest in specific scene graph locations and their attributes that are produced as a
result of evaluating the OpTree.
Internally, the Runtime has a number of other responsibilities including:
Managing the scheduling and evaluation of Ops.
Observing dependencies between Ops to ensure correct scene graph generation.
Caching of location and attribute data for retrieval.
Distribution of location and attribute data to clients.
The Runtime is able to use all the information it gathers from your interactions with it to efficiently manage
resources. For example, if you don't attach any Clients to the OpTree then it does not need to evaluate any Ops or, if
no dependencies exist between two Ops, it can concurrently schedule their evaluation to make best use of multicore
systems.
24 OP API | CORE CONCEPTS WITH GEOLIB3