Engine Interface Overview

The render process brackets an ongoing calculation as a whole. It is not to be confused with a operating system process or thread; rather it is a point of reference for the relevant entities in the Stage and Steam-Layer in need to connect to such a "rendering", and it holds the specific definitions for this calculation series. A render process corresponds to a single data stream to be rendered. Thus, when the play controller of some timeline in the model is in playing or paused state, typically multiple corresponding render processes exist.

A process is linked to a single stream data format (a → stream implementation type).
It is configured with frame quantisation and timings, and a model port identifier and channel selector.

The low level model is a network of interconnected render nodes. It is created by the build process to embody any configuration, setup and further parametrisation derived from the high-level description within the session. But the data structure of this node network is opaque and considered an implementation detail. It is not intended to be inspected and processed by outward entities (contrast this to the high-level model within the session, which provides an extensive discovery API and can be manipulated by model mutating commands). We just provide a set of query and information retrieval functions to suit the needs of the calculation process. The engine model is not persisted.

Thus, for any pair (port, time) it is possible to figure out a segment and an exit node to serve this position. The segmentation(s) for multiple ports might differ. To allow for effective dispatching, the model should provide convenience functions to translate these informations into frame number ranges. The mentioned quantisation and alignment constraints stem from the fact that the underlying media source(s) are typically themselves quantised and the timings might be manipulated within the processing chain. We might or might not be able to shift the underlying media source (it might be a live input or it might be tied to a fixed timecode)

In this context, a node is a conceptual entity: it is an elementary unit of processing. It might indeed be a single invocation of a processor (plugin or similar processing function), or it might be a chain of nodes, a complete subtree, it might represent a data source (file, external input or peer in case of distributed rendering), or it might stand for a pipeline implemented in hardware. The actual decision about these possibilities happened during the build process and can be configured by rules. Information about these decisions is retained only insofar it is required for the processing, most of the detailed type information is discarded after the wiring and configuration step. As mentioned above, each node serves two distinct purposes, namely to assist with the planning and dispatching, and to pull data by performing the calculations.

Nodes can be considered stateless — pulling a node has no effect outside the invocation context. While a node might actually be configured to drive a whole chain or subtree and propagate the pull request within this tree or chain internally, the node never propagates a pull request beyond its realm. The pull() call expects to be provided with all prerequisite data, intermediary and output buffers.

The dispatcher translates a render process (actually a calculation stream as part of a render process) into sequences of node invocations, which then can be analysed further (including planning the invocation of prerequisites) and scheduled. This mapping is assisted by the engine model API (to find the right exit node in the right segment), the render process (for quantisation) and the involved node’s invocation API (to find the prerequisites)

As nodes are stateless, they need to be embedded into an invocation context in order to be of any use. The node invocation has two distinct stages and thus the invocation API can be partitioned in two groups